std::stringstream无法真正插入文件内容，因其仅操作内存中文件快照；在指定位置插入需重排数据或借助外部存储，直接覆盖写入会导致后续数据丢失。
用 std::stringstream 无法真正“插入”文件内容
内存流（如 std::stringstream）只能操作内存中的字符串副本，它读进来的只是原文件的快照。哪怕你把新内容插在中间再写回原路径，本质仍是「覆盖写入」——操作系统不会帮你挪动磁盘上后续的数据块。
所以，想在第 100 字节处插入 5 个字节，又不丢数据，必须借助外部存储或重排逻辑。
常见错误现象：std::ofstream("file.txt") 看似“改了”，实则清空原文件再写，原内容只剩开头一段。
- 别幻想用
seekp()+write()在原文件里“挤”出空间——文件系统不支持这种随机插入 -
std::fstream以ios::in | ios::out打开后，seekp()定位再write()是覆写，不是插入 - 若原文件小（
安全插入的唯一可靠做法：用临时文件 + 原子重命名
核心思路是「读旧、拼新、写临时、换名」，绕过覆盖风险，也避免进程崩溃时文件损坏。
立即学习“C++免费学习笔记（深入）”；
使用场景：配置注入、日志补录、二进制 patch 前置头等需要保持原文件完整性的情况。
关键参数差异：std::ofstream temp_file("file.tmp", std::ios::binary) 必须加 std::ios::binary，否则 Windows 下换行符会被悄悄转义，导致长度错乱。
- 先用
std::ifstream in("file.txt", std::ios::binary)全量读取（或分段读，防爆内存） - 用
std::vector<char></char>或std::string拼接：前半段 + 插入内容 + 后半段 - 写入
"file.txt.tmp"这类临时名，**不要用file.txt.bak** ——万一程序崩在写一半，bak 反而成了脏数据 - 最后调用
std::filesystem::rename("file.txt.tmp", "file.txt")（C++17），这是原子操作，成功即生效，失败留 tmp 文件可查
跨平台临时文件名和权限坑
Windows 和 Linux 对临时文件路径、并发访问、删除语义处理不同，硬编码 "temp" 或 "./tmp" 很容易在 CI 或容器里失败。
错误现象：Permission denied（Linux 下 tmp 目录无写权）、Access is denied（Windows 下原文件被其他进程锁住）、No such file or directory（路径含中文或空格未转义）。
- 用
std::filesystem::temp_directory_path()拿系统推荐临时目录，再拼std::filesystem::unique_path() - 写临时文件前，检查目标路径父目录是否存在且可写：
std::filesystem::is_writable(dir) - 如果原文件有特殊权限（如 setuid），
rename()后权限会丢失——需在 rename 后手动std::filesystem::permissions()恢复 - 临时文件写完立刻
fflush()+fsync()（Linux）或FlushFileBuffers()（Windows），防止缓存未落盘就 rename
大文件插入时的内存与性能取舍
读 2GB 文件进内存再拼接，不是 OOM 就是卡死。这时候必须放弃“全载入”，改用流式分块 + 随机访问模拟。
适用条件：插入位置已知（如第 N 行、某段 marker 之后）、文件超 100MB、内存受限。
性能影响：顺序读两次（一次找插入点，一次复制）比单次全读慢约 1.8×，但内存占用从 GB 级压到 KB 级。
- 第一遍用
std::ifstream逐行或按 buffer（如 8KB）扫描，定位插入偏移pos - 第二遍打开两个流：
in（原文件，seekg(pos)）、out（临时文件），先写前半段（0~pos），再写插入内容，再循环读写 in 剩余部分 - 避免用
std::getline()处理二进制内容——它遇'\0'就停，改用read()+gcount() - 插入点靠近末尾时，直接追加更省事：
if (pos > file_size * 0.9) out ，别硬扛流式逻辑
最易被忽略的是插入点边界判断：文本模式下，行末换行符（"\n" 或 "\r\n"）算不算在“第 N 行”的长度里？这直接影响 pos 计算结果。二进制插入没这问题，但得自己确保插入内容与上下文编码一致。
