应使用双指针原地覆盖而非频繁调用erase：用write_idx记录写入位置，read_idx遍历字符串，仅保留需留字符并最后resize；频繁erase导致O(n²)时间复杂度，性能极差。
删除单个字符时别用 erase 循环调用
直接对 std::string 频繁调用 erase(pos, 1) 删除数百万次，性能极差——每次删除都触发内存搬移，时间复杂度接近 O(n²)。比如在 10MB 字符串里删 200 万个 'x'，可能卡住几秒甚至更久。
正确做法是用双指针原地覆盖：
- 用
write_idx记录保留字符应写入的位置 - 用
read_idx遍历整个字符串 - 只把需保留的字符拷贝到
write_idx，最后调用str.resize(write_idx)
示例：
size_t write_idx = 0;
for (size_t read_idx = 0; read_idx < str.size(); ++read_idx) {
if (str[read_idx] != 'x') { // 条件可替换为任意判断逻辑
str[write_idx++] = str[read_idx];
}
}
str.resize(write_idx);
要删多种字符？提前建查表比 find_first_of 快得多
str.find_first_of("abc") != std::string::npos 在循环里反复调用，每次都要线性扫描查找集，对数百万字符来说开销明显。尤其当要删的字符集固定（比如所有控制字符、空格、标点），用 256 元素的布尔数组查表是最快方式。
立即学习“C++免费学习笔记（深入）”；
- 声明
bool should_erase[256] = {};，初始化需删除的 ASCII 值为true - 遍历时直接
if (!should_erase[(unsigned char)str[read_idx]]) - 避免符号扩展问题：务必强制转
unsigned char
比 std::unordered_set<char> 查找快 3–5 倍，且无内存分配开销。
Unicode 字符串不能直接按字节删
如果字符串含 UTF-8 编码的中文、emoji 等，std::string 的 [] 操作只能访问字节，不是字符。按字节删会破坏编码，产生乱码或崩溃。
- 确认输入是否真为 UTF-8；如果不是（如 GBK、UTF-16），先转码再处理
- 真正按“字符”删，必须用 UTF-8 解码库（如
utf8cpp）或 C++20 的<charconv>+ 手动解析 - 若只是删 ASCII 范围内的字符（如所有数字、标点），且确保它们不会出现在多字节序列中间，则仍可用字节级双指针——但必须验证原始数据不含非法 UTF-8
没做编码检查就硬删，后期 debug 会发现某些位置删完后 std::string 无法被 std::cout 正常输出，或触发 std::runtime_error 抛出 “invalid UTF-8 sequence”。
内存分配影响比想象中大
即使用了双指针，如果原字符串很大（比如 100MB），而最终只保留 5%，resize 后释放的内存不一定立刻还给 OS——glibc 的 malloc 默认保留 arena，后续 new/malloc 可能复用，但进程 RSS 不降。
- 若需彻底释放内存，可 move 构造新 string：
str = std::string(str.begin(), str.begin() + write_idx); - 但注意这会触发一次分配+拷贝，仅在确实需要交还内存给系统时才用
- 更轻量的做法是调用
shrink_to_fit()（C++11 起），但它只是提示，不保证生效
实际压测中，shrink_to_fit() 在 libstdc++ 下对大字符串基本无效，clang libc++ 表现稍好——这点容易被文档误导。
