字符串部分掩码替换是满足可逆性、长度不变、格式保留的脱敏操作；C++中应使用substr拼接实现，严格校验边界与字符合法性，避免越界、乱码及非预期替换。
什么是字符串部分掩码替换，C++里怎么写最稳妥
不是所有“星号替换中间字符”的逻辑都叫脱敏——它得满足可逆性（如需要还原）、长度不变、不破坏格式（比如邮箱@前后要保留），且不能暴露原始数据分布。C++里直接用 std::string::replace 或迭代器修改容易越界或忽略边界条件，推荐用索引计算 + substr 拼接，控制力更强。
- 掩码起始位置必须 ≥ 0，结束位置必须 ≤ 原字符串长度，否则
substr会抛std::out_of_range - 对中文、emoji 等 UTF-8 多字节字符，按字节索引掩码会导致乱码；若输入确定为 ASCII（如手机号、邮箱本地部分），可放心按字节操作
- 掩码字符建议统一用
'*'，避免用空格或'#'——某些下游系统可能把空格 trim 掉，'#'在日志中易被误识别为注释
手机号脱敏：11位固定格式的掩码实现
国内手机号是典型固定长度+结构化字符串，前3位、后4位保留，中间4位掩码。关键不是“切几段”，而是验证长度和数字合法性，防止传入 "abc" 或 "12345" 导致静默错误。
std::string maskMobile(const std::string& s) {
if (s.length() != 11 || !std::all_of(s.begin(), s.end(), ::isdigit)) {
return s; // 不符合规范，不处理，避免污染数据
}
return s.substr(0, 3) + "****" + s.substr(7);
}- 不用
s[3] = s[4] = ... = '*'——std::string是不可变视图，直接赋值需确保可写，且易漏掉边界检查 - 用
s.substr(7)而非s.substr(7, 4)：后者在长度不足时截不出东西，前者自动取到末尾，更健壮 - 别用
std::regex做校验——启动开销大，纯长度+字符判断足够，且无异常风险
邮箱脱敏：按 @ 分割，只掩码本地部分中间字符
邮箱格式多变（a.b+c@d.e.f 合法），但通用策略是：保留第一个 '@' 前的首尾各1–2位，中间全掩码；域名部分通常不掩码（或按需整体掩码）。重点在于找到 '@' 位置，且不假设只有一个 @。
std::string maskEmail(const std::string& s) {
size_t at_pos = s.find('@');
if (at_pos == std::string::npos || at_pos < 2) return s;
std::string local = s.substr(0, at_pos);
if (local.length() <= 2) return s;
return local.substr(0, 1) + std::string(local.length() - 2, '*') + local.substr(local.length() - 1) + s.substr(at_pos);
}-
s.find('@')返回std::string::npos（即-1），不能直接当整数用，必须显式比较 - 掩码长度用
std::string(len, '*')构造，比循环 push_back 更高效，也避免手写for时i 这类 off-by-one 错误 - 域名部分（
s.substr(at_pos)）原样保留——如果需求是掩码域名，应单独拆出domain.substr(0, 1) + "***" + domain.substr(domain.rfind('.'))，而非模糊处理
为什么不要用 std::replace 或 std::fill 直接改原串
看起来最直觉的操作，恰恰最容易出生产事故。比如用 std::fill(s.begin() + 3, s.begin() + 7, '*') 掩码手机号，问题不在逻辑，而在调用方是否传了 const string 或 string_view——std::fill 要求迭代器可写，而 string_view 的 begin() 返回的是 const char*，编译不过；即使通过，若字符串内存被 mmap 或来自只读段，运行时会 SIGSEGV。
立即学习“C++免费学习笔记（深入）”；
- 所有脱敏函数输入统一用
const std::string&，输出新字符串，杜绝副作用 - 不依赖
std::string内部缓冲是否可写，也不假设其短字符串优化（SSO）状态 - 如果性能真成瓶颈（比如每秒脱敏百万条），再考虑基于
std::string_view+ 输出 buffer 的零拷贝方案，但那是另一层权衡，不是默认路径
真正难的不是写出能跑的代码，而是让 "138****1234" 和 "a***@b.com" 在各种异常输入下既不崩、也不泄露、还不多占内存——边界检查和返回原串的策略，比掩码逻辑本身更重要。
