c++oding="utf-8" ?>
用std::string::find配合erase循环删除最直接，需每次擦除后从当前位重新查找以避免跳过相邻重复；严格单词边界须手动检查分隔符；性能敏感时建议一次遍历构建新字符串。
用 std::string::erase 配合 std::string::find 循环删除最直接
这不是一个“一行解决”的问题，因为 std::string 没有原生的全局替换或批量删除接口。最稳妥、兼容性最好的做法是循环查找并擦除——尤其当你只删固定子串（如占位符 "{name}"、"%s" 或 "{{id}}"）时。
常见错误是边遍历边 erase 却没更新查找起始位置，导致跳过重叠匹配；或者用 replace 但误设长度，把非占位符也干掉了。
- 每次调用
find后，用返回值判断是否找到；若为std::string::npos，立即退出循环 -
erase后不要盲目加 1，而应把下次find的起始位置设为当前删除位置（因为擦除后后续字符前移，从该位置继续找才不会漏） - 避免在循环中反复构造临时字符串，比如用
substr拆分再拼接——性能差且易出错
std::string s = "Hello {name}, welcome to {place}!";
std::string placeholder = "{name}";
size_t pos = 0;
while ((pos = s.find(placeholder, pos)) != std::string::npos) {
s.erase(pos, placeholder.length());
}
// 结果: "Hello , welcome to {place}!"
用 std::regex_replace 要小心转义和性能开销
如果占位符含正则元字符（如 "{id}" 中的 { 和 }），直接传给 std::regex 会编译失败或行为异常。必须手动转义，而且 C++11 的 std::regex 在部分标准库实现（如 libstdc++）中性能较差、甚至不完全支持某些语法。
适用场景：占位符模式较复杂（如匹配 "{{.*?}}"），且你已确认运行环境的 regex 实现可靠。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 对
{、}、[、]、(、)、、^、$、.、+、*、?等全部转义，例如"\{\{[^}]*\}\}" - 不要用
std::regex_replace(s, re, "")处理超长字符串（>10KB），实测在 GCC 12 下可能慢一个数量级 - 若只需删固定字面量，regex 是杀鸡用牛刀，还引入异常风险（
std::regex_error）
处理嵌套或可变长占位符时，手写状态机比正则更可控
像 "{{user.name}}" 或 "%{version:short}" 这类带结构的占位符，正则容易误匹配（如把 "{{a}} {{b}}" 中的 "{{a}} {{b" 当成一个整体）。这时候靠 find + erase 也不够——它只能匹配字面量，无法解析结构。
简单状态机足够应付大多数模板场景，代码不到 30 行，无依赖、无异常、逻辑清晰。
- 用两个指针扫描：一个记录可能的起始（如遇到
'{'），一个推进读取；匹配到完整结束标记（如"}}"）才删除区间 - 遇到不匹配的中间字符（如
"{x}"中的x不符合命名规则），就重置起始位置，避免误删 - 如果占位符允许转义（如
"{not-a-placeholder}"），需额外检查前导反斜杠，并注意"\"本身要被识别为单个反斜杠
别忽略空字符串和连续占位符的边界情况
测试用例里常漏掉这些：
- 输入为空：
""——find返回npos，没问题；但若代码里先erase(0, ...)就崩了 - 占位符首尾相连：
"{a}{b}{c}"—— 循环删除时，删掉{a}后剩余"{b}{c}"，下一次find从位置 0 开始，能正确捕获{b} - 占位符部分重叠：
"{{{}}}"，想删所有"{}"，结果变成"{}"而非空串——这其实是预期行为，除非你明确要求贪心匹配，那就得换状态机
真正容易被忽略的是编码安全：如果字符串含 UTF-8 多字节字符，而占位符是 ASCII 字面量（如 "%s"），那 find 和 erase 依然安全；但若占位符本身是 Unicode（如 "①"），就必须确保编译器、源文件、运行时 locale 一致，否则 find 可能找不到。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
