白名单过滤不能用 std::remove_if + erase 组合，因其非真正 in-place 且查表性能差；应预建 256 字节布尔查找表并用双指针原地覆盖，最后 resize 截断。
白名单过滤为什么不能用 std::remove_if + std::string::erase 简单组合？
因为 std::remove_if 本身不保证原地（in-place）高效：它把保留字符前移，但后续 erase 仍要移动尾部内存；更关键的是，若白名单字符集很小（比如只允许 a-z0-9_），每次调用谓词都要遍历白名单或查表，性能差。实际场景中，白名单固定且长度有限（通常 ≤128），应预计算查找表。
用 256 字节布尔数组做 O(1) 白名单查表
ASCII 字符共 256 个取值（unsigned char 范围），直接建 bool allowed[256]{}，初始化时仅对白名单字符设为 true。这样每个字符判断是常数时间，且无分支预测失败开销。
实操建议：
- 白名单字符串如
"abcdefghijklmnopqrstuvwxyz0123456789_"，需转为unsigned char索引填表，避免符号扩展导致负索引 - 务必初始化整个数组为
false，否则未显式设置的项是未定义值 - 若输入含非 ASCII 字符（如 UTF-8 多字节），此方案只按字节过滤，不解析 Unicode；如需语义正确，必须先解码
bool allowed[256] = {}; // 全 zero-initialized
for (unsigned char c : whitelist) {
allowed[c] = true;
}
双指针原地覆盖实现真正 in-place 过滤
用 write 指针记录下一个可写位置，read 指针遍历全部字符；只对 allowed[*read] 为 true 的字符执行 s[write++] = *read。结束后调用 s.resize(write) 截断。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
关键点：
- 不能用
std::string::operator[]直接赋值后自增（如s[i++] = c），因resize前字符串容量未变，越界写入未定义 - 必须用
resize收尾，否则字符串逻辑长度不变，多余字符仍可被迭代器访问 - 若白名单为空，
write始终为 0，resize(0)正确清空
size_t write = 0;
for (size_t read = 0; read < s.size(); ++read) {
unsigned char c = static_cast<unsigned char>(s[read]);
if (allowed[c]) {
s[write++] = s[read];
}
}
s.resize(write);
性能陷阱：std::string 的 small string optimization（SSO）影响
短字符串（通常 ≤15 或 22 字节）存在栈上，resize 不触发堆分配，快；但长字符串反复 resize 可能引发多次 realloc。若已知目标长度上限，可提前 reserve 避免扩容。
注意：
-
reserve不改变size()，只是预留容量；过滤后仍需resize - 白名单越严格，输出越短，
reserve过大会浪费空间；保守做法是s.reserve(s.size())（即不额外预留） - 若在循环中高频调用该过滤函数，把
allowed数组声明为static const或传入引用，避免重复初始化
白名单字符集是否包含空格、制表符、换行符，直接影响过滤后字符串是否“干净”——这点常被忽略，调试时发现结果里还有 \t，才发现白名单漏了 '\t'。
