既然你的问题包含了一系列其他问题，那么我就列出一系列其他答案来回答你。

cudaMallocPitch/cudaMemcpy2D：

首先，cuda运行时API函数（如cudaMallocPitch和cudaMemcpy2D）实际上不涉及双指针分配或2D（双下标）数组。这很容易通过查看文档并注意函数原型中的参数类型来确认。src和dst参数是单指针参数。它们不能被双下标，或双重解引用。对于其他示例用法，这里是关于此的许多问题之一。这里是一个完整的示例用法。另一个涵盖与cudaMallocPitch/cudaMemcpy2d用法相关的各种概念的示例在这里。相反，正确的思考方式是它们与 pitched 分配一起工作。此外，如果已使用一组malloc创建基础分配，则不能使用cudaMemcpy2D传输数据（或new，这种类型的主机数据分配构造特别不适合于处理设备上的数据。

常规，动态分配的2D用例：

如果你想学习如何在CUDA内核中使用动态分配的2D数组（这意味着你可以使用双下标访问，例如data[x][y]），那么cuda tag info page包含了这个“规范”问题，它是here。Talonmies给出的答案包括适当的机制，以及适当的警告：

• 存在额外的非平凡的复杂性
• 该访问通常不如1D访问有效，因为数据访问需要解引用2个指针，而不是1个。

(note分配一个对象数组，其中对象有一个指向动态分配的嵌入指针，本质上与2D数组概念相同，你在问题中链接的the example是一个合理的演示）
此外，here是用于构建通用动态分配2D阵列的推力方法。

展平：

如果你认为你必须使用一般的2D方法，那么就去吧，这不是不可能的（尽管有时候这个过程是people struggle！）然而，由于增加的复杂性和降低的效率，这里的规范“建议”是“扁平化”你的存储方法，并使用“模拟”2D访问。这里是讨论“扁平化”的许多问题/答案的例子之一。

一般动态分配3D用例：

当我们将其扩展到3（或更高！）维时，一般情况变得过于复杂，难以处理，IMO。额外的复杂性应该强烈地激励我们寻求替代方案。三下标的一般情况在实际检索数据之前涉及3个指针访问，因此效率更低。下面是一个完整的示例（第二个代码示例）。

特殊情况：编译时已知的数组宽度：

请注意，当数组维度为（s）（width，在2D数组的情况下，或3D数组的3个维度中的2个）在编译时是已知的。在这种情况下，通过适当的辅助类型定义，我们可以“指示”编译器应该如何计算索引，在这种情况下，我们可以使用双下标访问，其复杂性比一般情况低得多，* 和 * 没有由于指针追逐而导致的效率损失。只需要解引用一个指针来检索数据（不考虑数组维度，如果对于n维数组在编译时已知n-1维）。这里已经提到的答案中的第一个代码示例（第一个代码示例）给出了3D情况下的完全工作示例，并且这里的答案给出了这种特殊情况的2D示例。

双下标主机代码，单下标设备代码：

最后，另一种方法选项允许我们轻松地混合2D仅使用1D时 * 主机代码 * 中的（双下标）访问（单下标，可能具有“模拟2D”访问）。这里有一个工作示例。通过将底层分配组织为连续分配，然后构建指针“树”，我们可以在主机上启用双下标访问，尽管该示例没有示出，但是可以扩展该方法以基于平面分配和手动创建的指针“树”在设备上创建双下标访问系统，然而，这将具有与上面给出的2D通用动态分配方法大致相同的问题：它将涉及双指针（双解引用）访问，因此效率较低，并且存在与构建指针“树”相关联的一些复杂性，以用于设备代码（例如，可能需要附加的cudaMemcpy操作）。
从上述方法中，你需要选择一个适合你的胃口和需要。没有一个单一的建议，适合每一个可能的情况。

这个答案进入了对两类实现/方法之间的差异的更细粒度的解释。