C++指针本身不提供内存保护，真正起作用的是操作系统API（如mprotect/VirtualProtect）配合页对齐内存分配；需用mmap/VirtualAlloc分配内存后调用保护函数，且保护粒度为内存页。
指针本身不提供内存保护，别被名字误导
直接说结论：int*、void* 或 std::unique_ptr 这类指针类型，**完全不带内存保护能力**。C++ 标准指针只是地址的包装，读写越界、重复释放、悬垂访问，编译器默认不管，运行时也不会自动拦截。所谓“用指针实现内存保护”，本质是借助指针作为入口，配合操作系统级机制（如 mprotect、VirtualProtect）或硬件特性（如 MPU/MMU），再加一层控制逻辑。
真正起作用的是 mmap + mprotect（Linux）或 VirtualAlloc + VirtualProtect（Windows）
想让某块内存变成只读/不可执行/不可访问，必须调用系统 API 修改页表属性。指针只是帮你定位到那一页的起始地址。常见错误是：先 new 一块内存，再试图对 new 返回的指针调用 mprotect —— 失败，因为 new 分配的内存不属于你可直接控制的映射区。
- 正确做法：用
mmap(nullptr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0)分配页对齐内存，拿到指针后立即用mprotect(ptr, size, PROT_READ)锁定 - 注意
mprotect的地址必须页对齐（通常 4096 字节），传入非对齐地址会失败并返回-1，errno设为EINVAL - Windows 下对应：用
VirtualAlloc分配MEM_COMMIT | MEM_RESERVE，再用VirtualProtect(ptr, size, PAGE_READONLY, &old_prot)
用 RAII 封装指针 + 保护状态，避免手动管理出错
裸调系统 API 容易漏掉恢复权限、忘记 munmap，导致内存泄漏或后续访问异常。推荐封装成类，把指针生命周期和保护状态绑定：
class ProtectedBuffer {
void* ptr_;
size_t size_;
public:
ProtectedBuffer(size_t s) : size_(s) {
ptr_ = mmap(nullptr, s, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (ptr_ == MAP_FAILED) throw std::bad_alloc{};
}
~ProtectedBuffer() { munmap(ptr_, size_); }
void protect_readonly() {
// 确保地址页对齐
void* page = reinterpret_cast<void*>(
reinterpret_cast<uintptr_t>(ptr_) & ~(4095UL));
mprotect(page, size_, PROT_READ);
}
template<typename T> T* get() { return static_cast<T*>(ptr_); }
};
关键点：protect_readonly() 里必须对齐地址；get() 返回的指针仍可强制转型，但写操作会触发 SIGSEGV（Linux）或 ACCESS_VIOLATION（Windows）——这是你想要的“保护”生效的表现。
立即学习“C++免费学习笔记（深入）”；
警惕 C++ ABI 和优化带来的意外行为
即使你成功设了只读页，某些代码仍可能绕过检查：
-
const_cast强转后写入：依然触发段错误，不是“绕过”，而是你本就不该这么做 - 编译器常量折叠：比如
const int x = 42;，哪怕它在受保护页上，编译器可能直接内联值，不访问内存 - LTO（链接时优化）可能将跨函数的指针传递优化掉，导致你保护的地址实际未被使用
- ASLR 和堆栈随机化会让每次运行地址不同，调试时别硬编码地址
最易忽略的一点：保护粒度是**内存页**（通常 4KB），不是单个对象或字段。一个 class 实例若跨页，部分字段可能仍可写；想精细控制，得自己按页拆分对象布局，代价很高。
