指针变量的大小只取决于系统位数，和所指向类型无关；在相同编译环境下，int、char、double、MyClass* 等所有指针大小均相同，因其本质是存储内存地址的整数，地址宽度由平台决定。
指针变量的大小只取决于系统位数，和所指向类型无关
在 C++ 中，int*、char*、double* 甚至 MyClass**，只要是指针，它们的大小在同一个编译环境下完全一致。这不是语言设计的“巧合”，而是因为指针本质是存储内存地址的整数——而地址空间的宽度由目标平台决定。
常见误区是认为 sizeof(char*) ，这是错的。实际结果只看编译目标：
- 32 位系统（或编译为
-m32）：所有指针都是4字节 - 64 位系统（默认 x86_64）：所有指针都是
8字节
你可以用 std::cout 验证，结果不会因 int 改变，只会随 -m32 / -m64 编译选项切换。
32 位与 64 位下指针差异直接影响可寻址内存上限
指针占 4 字节意味着最多表达 2^32 = 4,294,967,296 个不同地址，即理论最大寻址空间为 4 GiB（无论物理内存多少）。64 位指针虽定义为 8 字节（2^64 地址空间），但当前主流 CPU 实际只实现 48 位或 57 位地址线，Linux x86_64 默认用户空间约 128 TiB，远超 32 位限制。
立即学习“C++免费学习笔记（深入）”；
这意味着：
- 在 32 位程序中，即使机器装了 16 GiB 内存，单个进程也无法直接访问超过 ~3.5 GiB 的虚拟地址（受 OS 分配策略影响）
- 64 位程序没有这个硬性天花板，但指针变大也带来额外内存开销：比如
std::vector存 100 万个指针，在 64 位下比 32 位多用 4 MiB
混用 32/64 位指针会导致链接失败或运行时崩溃
如果你在 64 位系统上用 g++ 编译却加了 -m32，而链接的库是 64 位的（如系统 libstdc++.so），会报类似 file in wrong format 的错误；反过来，32 位程序加载 64 位共享库会直接失败。
更隐蔽的问题出现在跨平台代码中：
- 把指针强制转成
int或long存储（如long addr = (long)ptr;）：在 64 位 Linux 上long是 8 字节，没问题；但在 Windows 64 位上long仍是 4 字节，会截断高位 → 崩溃 - 正确做法是用
intptr_t或uintptr_t（定义在
结构体中指针对齐可能放大内存占用
指针本身大小固定，但它在结构体里的偏移受对齐规则影响。例如：
struct A {
char c;
int* p; // 在 64 位下是 8 字节
};在大多数 64 位 ABI（如 System V AMD64）中，int* 要求 8 字节对齐，所以 c 后面会填充 7 字节，整个结构体大小变成 16，而不是 1+8=9。这比单纯看指针字节数更容易被忽略。
关键点：
- 结构体总大小一定是其最宽成员对齐值的整数倍（这里最宽成员是
int*，对齐值为8） - 用
#pragma pack(1)可禁用填充，但可能降低访问性能，尤其在 ARM 等架构上触发对齐异常
实际项目中，如果结构体频繁创建且含多个指针，对齐带来的“隐性膨胀”可能比指针自身字节更值得优化。
