std::shared_ptr不能直接用于写时复制，因其引用计数不检测内容修改，需手动封装cow_String并在所有非常量成员函数中调用make_unique()实现分离；避免裸指针泄漏和c风格函数绕过检查。
为什么 std::shared_ptr 不能直接用于影子拷贝？
因为 std::shared_ptr 的引用计数只管“谁还持有指针”，不管“谁在读写对象内容”。影子拷贝要求：多个对象共享同一份底层数据，直到其中某个开始修改——这时才真正复制。而 shared_ptr 没有内置的“写时检查”机制，你调用 get() 拿到原始指针后，完全可能在不通知计数器的情况下直接改内容。
所以必须自己封装一层，在所有可写访问入口（比如非 const 成员函数、operator[]、data() 等）里插入“是否唯一”的判断和复制逻辑。
如何手动实现写时复制的 cow_string 类？
核心是把数据和引用计数放在堆上共用结构体里，每次写操作前调用 make_unique() 检查并分离：
-
make_unique()不是标准函数，得自己写：若m_refcount > 1，则new一份副本，delete原数据，更新指针和计数 - 所有非常量成员函数（如
operator[]、append()、clear()）开头必须调用它 - const 成员函数（如
size()、c_str()）可以跳过，它们不修改数据 - 注意构造/析构时对
m_refcount的原子增减（多线程下建议用std::atomic_int）
示例片段：
立即学习“C++免费学习笔记（深入）”；
void cow_string::make_unique() { if (m_refcount.load() > 1) { char* new_buf = new char[m_size + 1]; memcpy(new_buf, m_data, m_size + 1); delete[] m_data; m_data = new_buf; m_refcount.store(1); } }哪些操作会意外绕过写时复制？
最常见的是通过 data() 或 operator[] 获取非 const 指针后，用 C 风格函数（如 strcpy、strcat）直接操作——这些函数不会触发你的 make_unique() 逻辑。
- 避免暴露裸指针：不要提供非 const
data()，或返回const char*；如必须提供，文档里标红警告 - 禁用隐式转换：不要定义
operator char*()，防止被传给旧接口 - STL 容器迭代器也不安全：比如
begin()返回非 const 迭代器后，用std::fill写入，同样跳过检查 - 移动语义要重置计数：移动构造/赋值后，源对象应设为 nullptr 且 refcount 归零，否则残留指针可能引发 double-free
性能与兼容性陷阱
写时复制不是银弹。小字符串（比如短于 16 字节）频繁拷贝反而比直接复制慢，因为每次都要检查原子变量、分支预测失败、缓存行失效。
- 考虑 SSO（Short String Optimization）：小字符串放对象内部，大字符串才走堆+引用计数
- gcc 的
std::string在 5.0 之前默认用 COW，但 c++11 标准明确禁止了，所以跨编译器/标准库不可移植 - 调试时注意：GDB 可能无法自动识别自定义 COW 对象的长度，
print s.size()是安全的，但print s.m_data显示的可能是共享内存地址 - 如果类支持多线程，
m_refcount必须是std::atomic_int，且make_unique()中的 load/store 要用memory_order_relaxed就够了——只要保证计数本身不乱，复制动作的顺序由临界区保护
实际用起来，最难的不是复制逻辑本身，而是守住所有写入口、堵住所有裸指针泄漏点。一旦漏掉一个 operator+= 或忘了重载 assign()，整个 COW 就形同虚设。