应使用re.sub而非str.replace，因其支持词边界（\b）、负向断言等正则特性，可精准处理嵌套敏感词（如“苹果”与“苹果手机”），避免漏判或误杀；需预编译正则、用re.escape转义特殊字符，并结合IGNORECASE标志确保鲁棒性。
敏感词匹配用 re.sub 还是 str.replace？
直接用 str.replace 只能做精确字符串替换，遇到“苹果”和“苹果手机”这种嵌套词会漏判或误杀；re.sub 支持正则、可控制边界（比如加 \b），更适合真实场景。但要注意：正则模式编译一次复用，否则反复编译拖慢性能。
常见错误是没加 re.escape() 处理敏感词里的特殊字符，比如“C++”、“/dev/null”这类词直接进 re.compile 会报 re.error: bad escape。
- 先用
re.escape(word)转义每个敏感词 - 用
re.compile('|'.join(escaped_words), re.IGNORECASE)构建单个正则对象 - 替换时用
lambda m: '*' * len(m.group())保持遮蔽长度一致
文件逐行读取时如何避免内存爆炸？
大文件（比如几百MB日志）一次性 read() 会把全部内容加载进内存，容易触发 MemoryError。必须流式处理——按行读、逐行过滤、立即写入输出文件。
注意编码问题：Windows记事本存的GBK文件、Linux日志常用UTF-8、还有带BOM的UTF-8，不指定 encoding 参数会导致 UnicodeDecodeError。建议显式传 encoding='utf-8'，出错时再 fallback 到 gbk 或用 errors='ignore'。
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 用
with open(... , encoding='utf-8', errors='ignore') as f: - 循环
for line in f:，别用f.readlines() - 每行处理完立刻
output_file.write(filtered_line)，别攒列表
如何让“张*”、“李**”这类部分遮蔽更自然？
全替成星号太生硬，用户可能希望保留首字（如“张***”→“张**”）。这需要在 re.sub 的替换函数里判断匹配长度：1字留1，2字留1，3字以上留前1后1，中间用星号填充。
别硬写条件分支，用 len(m.group()) + 字符串切片更稳。还要注意中文字符占2字节但 len() 返回的是Unicode码点数，对中文也适用——Python 3中 len('张') 就是1。
- 替换函数写成：
lambda m: m.group()[0] + '*' * max(0, len(m.group()) - 2) + (m.group()[-1] if len(m.group()) > 2 else '') - 如果要求严格保留原格式（比如中英文混排），得用
re.finditer手动定位再拼接，避免正则跨字符截断
敏感词列表动态加载与热更新怎么做？
硬编码在代码里改词要重启程序，生产环境基本不可行。最简方案是把词表存在纯文本（每行一个词）或 JSON 文件里，启动时读一次；进阶做法加个定时检查文件修改时间，变化时重新加载。
但要注意并发风险：多线程同时读同一个词表文件一般没问题，但如果用 mmap 或共享内存优化，就得加锁。多数场景下，每次过滤前调用一次 load_sensitive_words() 函数足矣——只要词表不大（几千条以内），加载开销可忽略。
- 词表路径用配置变量控制，别写死
'./words.txt' - 加载失败时打印警告并沿用旧词表，别直接崩掉主流程
- 测试时用
os.utime()模拟文件更新，验证热加载逻辑
实际部署时最容易被忽略的是词表加载时机和异常兜底——不是所有文件都能顺利打开，也不是所有词都符合预期格式，这些边界情况不处理，上线后第一份脏数据进来就暴露了。
