RAII与智能指针通过绑定资源生命周期至对象作用域，确保构造获取、析构释放，杜绝裸指针导致的泄漏与悬垂；敏感资源须封装为禁拷贝类，仅提供受限移动语义或只读接口，配合能力令牌（Capability）实现最小权限隔离。
用 RAII + 智能指针控制资源生命周期，避免越权释放或重复访问
最小权限隔离不是靠“不给权限”实现的，而是让每个模块只持有它真正需要的、且无法滥用的资源句柄。裸指针、全局句柄、原始 new/delete 都会破坏这个前提。
典型错误现象：std::shared_ptr 被随意拷贝传给无关模块，结果某个子模块调用 reset() 导致其他模块访问悬空资源；或者模块 A 拿到一个 GPUHandle 后直接调用底层驱动 API，绕过权限校验。
- 敏感资源（如 GPU 内存、加密密钥句柄）必须封装为私有类，禁用拷贝，只提供受限的移动语义或只读视图
- 对外暴露的接口应返回
std::unique_ptr这类抽象接口指针，而非具体类型 - 构造函数中完成权限检查（例如：传入 capability token），失败则抛异常或返回
nullptr，绝不留半初始化对象
模块间通信必须走能力令牌（capability），禁止暴露原始系统调用
零信任架构下，模块之间不能默认互信。一个模块想执行某操作，必须显式持有对应能力令牌，而不是靠“我在同一个进程里”这种隐含假设。
常见错误场景：渲染模块直接调用 open("/dev/dri/renderD128", O_RDWR)，一旦该模块被攻破，攻击者就拿到完整 GPU 设备权限；或者网络模块把 socket fd 直接传给业务模块，后者可任意 sendto() 或 close()。
- 所有跨模块资源访问，统一通过
Capability或Capability类型参数传递 - 能力令牌本身不可伪造：构造时绑定 caller identity（如模块签名 hash）、时效性（
valid_until）、作用域（target_device_id） - 底层系统调用入口（如
ioctl(),sendmsg()）必须仅在 capability 的execute()方法内调用，且做二次校验
用沙箱进程隔离高风险模块，别指望单进程内靠代码逻辑防住 ROP
再严格的 C++ 接口设计也挡不住内存破坏类漏洞（UAF、栈溢出）触发的任意代码执行。只要模块共享地址空间，一次失陷就等于全盘沦陷。
容易被忽略的现实：Clang 的 AddressSanitizer 和 UndefinedBehaviorSanitizer 只用于开发期检测，上线后无效；而 std::shared_ptr 的引用计数本身也可能被堆喷覆盖篡改。
- 图形渲染、音视频解码、第三方解包器等高风险模块，必须运行在独立进程，通过 IPC（如 Unix domain socket + capability handshake）通信
- 主进程只保留策略决策和状态协调逻辑，不做实际数据处理；沙箱进程启动时 drop capabilities（Linux
cap_drop）、chroot、seccomp-bpf 白名单限制 - IPC 协议必须带完整性校验（如 HMAC-SHA256 over message + nonce），防止中间篡改 capability 作用域
信号级故障拦截只能兜底，不能替代权限设计
有人用 signal(SIGSEGV, handler) 捕获段错误来“防止崩溃”，这本质上是错觉。信号处理器里你无法安全地恢复执行上下文，更无法修复已被破坏的堆/栈/全局状态。
真实后果：捕获 SIGSEGV 后继续运行，可能触发后续 SIGABRT（比如 std::vector::at() 抛异常时发现 allocator 已损坏），或者静默写坏关键数据结构。
-
signal()仅可用于记录日志、触发模块重启、通知监控系统，绝不能用于“继续服务” - 若需容错恢复，必须配合进程级隔离：信号触发后杀掉当前沙箱子进程，由主进程拉起新实例并重置 IPC channel
- 不要在信号处理器里调用
malloc()、std::cout、锁操作——这些都不是 async-signal-safe 函数
最小权限不是加一堆 if (has_permission()) 判断，而是让没权限的代码根本拿不到可操作的对象。很多团队卡在“模块拆开了但还是互相 include 头文件”，根源是没把 capability 作为一等公民建模进类型系统。真正的隔离，始于编译期类型检查，成于运行期进程边界，补于信号兜底——三者缺一不可。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
