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