白名单清洗不能用std::remove_if+erase，因其触发多次内存移动，性能差；应采用双指针原地遍历+布尔查找表（O(n)），预建表、强制unsigned char转换、最后resize截断。
白名单清洗为什么不能用 std::remove_if + std::string::erase？
因为这会触发多次内存移动：先标记、再搬移、最后截断，对长字符串（尤其 >10KB）性能损耗明显。原地清洗的核心是「只遍历一次，写指针紧随读指针推进」，避免重复拷贝。
常见错误是把白名单逻辑写成每次查 std::string::find_first_of —— 它内部是线性扫描，O(n×m) 复杂度；换成布尔查找表后可压到 O(n)。
- 白名单字符集若 ≤256 个（如 ASCII 子集），直接用
std::array<bool></bool>建表，索引即字符值 - 若含 Unicode（UTF-8 编码下多字节），需先解码再查表，但多数清洗场景只需 ASCII 白名单
- 注意：
char有符号性问题，查表前强制转为unsigned char，否则负值索引越界
如何用双指针实现真正原地清洗（无额外分配）
读指针 i 扫描整个字符串，写指针 w 指向当前有效字符应写入位置。仅当 s[i] 在白名单中时，才执行 s[w++] = s[i]；扫描完后调用 s.resize(w) 截断尾部无效内容。
关键点：不调用任何 std::string 的插入/删除接口，全程只读写底层字符数组。
立即学习“C++免费学习笔记（深入）”；
- 必须在循环前预建白名单表，避免每次迭代都做字符串搜索或 set 查找
-
resize()是唯一一次内存调整，且只缩不扩，不会触发新分配 - 若字符串本身是
const或来自只读内存（如字面量），此法不可用——原地清洗隐含可写前提
std::string clean_inplace(std::string& s, const std::string& whitelist) {
std::array<bool, 256> is_allowed{};
for (unsigned char c : whitelist) {
is_allowed[c] = true;
}
size_t w = 0;
for (size_t i = 0; i < s.size(); ++i) {
unsigned char c = static_cast<unsigned char>(s[i]);
if (is_allowed[c]) {
s[w++] = s[i];
}
}
s.resize(w);
return std::move(s);
}
白名单含控制字符或空格时的典型陷阱
比如想保留空格、数字和字母，却漏掉 ' '（空格 ASCII=32）—— 表里对应项没置 true，结果所有空格被删。更隐蔽的是换行符 '\n'（10）、制表符 '\t'（9）等，容易被忽略。
- 构造白名单字符串时，显式写出所有需保留字符，不要依赖「非黑名单即白名单」的模糊逻辑
- 若白名单来自配置文件或用户输入，需校验是否含 \0（C 字符串截断）或非法 UTF-8 字节（导致后续解码失败）
-
std::array<bool></bool>默认初始化为false，务必确保所有合法字符都被显式设为true，未设即拒绝
性能敏感场景下，std::string_view 能否替代 std::string&？
不能。清洗必须修改原字符串内容，std::string_view 是只读视图，无法写入。有人试图返回新字符串 + 移动语义，但这已脱离「原地」要求，且涉及堆分配。
若上游无法提供可写 std::string&，只能退化为「生成新字符串」方案：单次遍历 + 预估容量（如用 whitelist 中出现频率估算），再用 reserve() 减少重分配。
- 原地清洗的前提是：你拥有该
std::string的所有权且允许修改 - 如果字符串来自
const char*且不能改源内存，就不存在「原地」一说，得先拷进std::string - 某些嵌入式环境禁用堆分配，此时必须坚持原地方案，且白名单表必须是栈上静态结构
char 符号性、可写权限这三点，任一出错都会让「原地」变成假象——要么悄悄分配内存，要么删错字符，要么崩溃。 
