用 std::vector::at() 替代 [] 可捕获越界访问并抛出异常，适用于调试和关键索引校验；std::span 与 std::unique_ptr 组合使用可兼顾内存安全与边界控制；ASan 是开发阶段必备的越界检测工具；string_view 需谨慎管理底层字符串生命周期。
用 std::vector::at() 替代 [] 做索引访问
越界读写最常见于数组/容器索引操作，[] 不做检查，而 at() 会抛出 std::out_of_range 异常——这是最轻量、最直接的运行时防护。
适用场景：调试阶段快速暴露问题，或对关键索引（如用户输入、配置解析结果）必须强制校验。
-
std::vector<int> v = {1,2,3}; v.at(5);</int>立即崩溃并提示越界位置，比静默越界后行为不可控强得多 - 发布构建中
at()仍有检查开销（哪怕很小），高频循环内慎用；但比起越界导致的偶发 crash 或数据污染，这点开销值得 - 注意：
at()对空容器调用at(0)同样抛异常，别假设“非空就安全”
禁用裸指针 + new/delete，改用 std::unique_ptr 和 std::span
裸指针是越界温床：无长度信息、无所有权语义、无法自动绑定边界。C++17 起 std::span 是更安全的替代方案。
常见错误现象：char* buf = new char[1024]; process(buf, 2048); —— 函数内部按 2048 处理，实际只分配了 1024，必越界。
立即学习“C++免费学习笔记（深入）”；
- 用
std::unique_ptr<char> buf(new char[1024]);</char>确保自动释放，但不解决越界 - 真正关键的是传参时用
std::span<const char>(buf.get(), 1024)</const>，接收方函数签名改为void process(std::span<const char> data)</const>，编译期/运行期都能约束访问范围 -
std::span不接管内存，所以不能替代unique_ptr；二者组合使用才是正解：一个管生命周期，一个管视图边界
编译期加 -fsanitize=address（ASan），别只靠测试覆盖
很多越界在特定输入下才触发，手工测试极难覆盖。ASan 能在运行时捕获绝大多数堆/栈/全局区越界，并精准定位到行号和访问偏移量。
性能影响：启用 ASan 后程序变慢 2–3 倍，内存占用翻倍，但它不是用来上生产的——是开发和 CI 阶段的必备开关。
- Clang/GCC 都支持：
g++ -fsanitize=address -g main.cpp，然后直接运行，越界立刻报红字堆栈 - 注意：ASan 无法检测未初始化内存读（那是 UBSan 的事），也不能捕获所有类型越界（比如某些结构体内存重排导致的隐式越界）
- 常见坑：链接静态库时若库本身没用 ASan 编译，越界可能漏报；确保整个依赖链都带
-fsanitize=address
std::string_view 不等于安全，小心它引用的原字符串提前析构
std::string_view 因为零拷贝常被当作“安全替代”，但它只是视图——底层指针和长度全靠外部保证有效。一旦源 std::string 生命周期结束，string_view 就变成悬垂指针，越界访问随时发生。
典型场景：函数返回 string_view 指向局部 string，或从临时 string 构造 string_view 后继续使用。
- 错：
std::string_view bad() { std::string s = "hello"; return s; }——s出作用域即销毁，返回的string_view指向已释放内存 - 对：只用
string_view接收参数（如void f(std::string_view sv)），且确保调用方传入的字符串生命周期长于函数执行时间 - 更稳妥：不确定生命周期时，老实用
std::string；或者用absl::string_view（带调试断言）辅助排查
越界问题从来不在“会不会发生”，而在“什么时候暴露”。用对工具只是第一步，真正难的是让边界意识渗透到每处指针传递、每次索引计算、每个临时对象的生命周期判断里。
