到目前为止，我认为 32 位处理器可以使用 4 GiB 的内存，因为 2 32是 4 GiB，但是这种方法意味着处理器的word size = 1 byte。因此，具有 32 位程序计数器的进程可以寻址 2 32 个不同的内存字，因此我们有 4 GiB。
但是如果处理器的字长大于 1 字节，我相信现在大多数处理器都是这种情况（我的理解是字长等于数据总线的宽度，所以具有 64 位数据总线的处理器必须有一个字大小= 8字节）。
现在具有 32 位程序计数器的同一处理器可以寻址 2^32 个不同的内存字，但在这种情况下，字大小为 8 个字节，因此它可以寻址更多与 4 GiB 相矛盾的内存，那么我的论点有什么问题？
CPU（至少 x86 系列 32 位）必须能够访问4GB 空间中的任何字节/字/双字。因此，一条指令被编码为目标字长和内存地址（通常）属于不同的位域。所以CPU访问byte还是dword都没有关系，但是编码后的内存地址必须相同。
请注意，32 位操作系统和 x86 CPU 在技术上能够使用PAE模式访问超过 4GB 的地址空间。但它不受当前 Windows 操作系统系列（服务器版本除外）的支持。某些版本的 WinXP 以及 Linux 和其他 32 位操作系统可以寻址 x86 CPU 上的 64GB 内存。
此外，通常操作系统会保留部分虚拟地址空间（用于操作系统内核、视频内存等），因此用户程序可以使用，例如，操作系统可以在每个进程中寻址的 4GB 内存中不超过 3GB 的 RAM。
你的前提不正确。32 位架构可以处理超过 4GB 的内存，就像大多数（如果不是全部）8 位微控制器可以使用超过 256 字节的内存一样。事实上，一个 32 位程序计数器可以寻址 2 32 个不同的内存位置，但字可寻址内存仅用于非常特殊用途的架构中，例如过去的DSP或古董架构。通用计算的现代架构都使用字节可寻址内存
即使在 32 位字节可寻址架构中，也有许多方法可以访问超过 4GB 的内存。例如，64 位 JVM 可以使用 32 位指针使用压缩的 Oops寻址 32GB 内存。查看JVM 压缩 Oops 背后的技巧
32 位 x86 CPU 还可以使用PAE寻址 64GB（或更高版本中的更多）内存。它基本上在 TLB 中增加了另一个间接级别，地址中多了几位。这允许整个系统访问超过 4GB 的内存。但是，应用程序中的指针仍然是 32 位长，因此每个进程仍然最多限制为 4GB。ARM 上的模拟是LPAE。
每个进程的 4GB 地址空间通常分为用户和内核空间（在 Meltdown 之前），因此更加限制了用户内存。有几种方法可以解决此问题