文件内容清洗需按业务场景定义“特殊字符”，不可统一删除；如CSV需转义双引号和换行，HTML需实体编码
写入文件前过滤特殊字符，本质是“按业务定义清洗内容”，不是统一删掉某些符号——os.WriteFile 或 io.WriteString 本身不校验字符合法性，出问题全在你传进去的字符串上。
先明确“特殊字符”到底指什么
不同场景下，“特殊字符”的含义完全不同：
- 文件名里不允许
/、\0、..，但它们在文件内容里完全合法 - 日志写入时要剔除控制字符（如
\x00–\x1F），否则可能破坏日志系统解析 - 导出 CSV 时需转义双引号
"和换行符\n，否则破坏格式 - 生成 HTML 文件必须对
、<code>>、&做 HTML 实体编码，否则引发 XSS 或解析错误
别用“过滤所有非 ASCII 字符”这种模糊策略——中文、emoji 是合法内容，硬删会丢数据。
用 strings.Map 做轻量级、零分配清洗
如果只是剔除或替换少量非法字符（比如日志中控制字符），strings.Map 是最省资源的方式，不分配新切片，也不启动正则引擎：
立即学习“go语言免费学习笔记（深入）”；
cleaned := strings.Map(func(r rune) rune {
// 只保留可打印 ASCII + 换行、制表、回车
if r >= 0x20 && r <= 0x7E {
return r
}
if r == '\n' || r == '\t' || r == '\r' {
return r
}
return -1 // 删除该 rune
}, input)
注意：strings.Map 对每个 rune 单独判断，天然支持 Unicode；传入 "" 返回空字符串，不会 panic。
写入前必须做 utf8.ValidString 校验
用户上传、网络接收或跨系统拼接的字符串，可能含非法 UTF-8 字节序列（如截断的 emoji、GBK 混入）。Go 的 string 类型不强制校验，但某些底层系统调用（如 Windows 控制台输出、部分日志后端）会直接崩溃或静默失败：
- 用
utf8.ValidString(s)快速检查，返回false就说明字符串损坏 - 修复不可靠：不要用
strings.ToValidUTF8（不存在）或盲目替换，应记录原始字节并告警 - 若必须容错，可用
bytes.Runes+utf8.DecodeRune手动跳过非法字节，但会丢失原始语义
这个检查常被跳过，直到某天在 Windows 上写入含乱码的昵称时，os.WriteFile 突然返回 invalid argument 错误才暴露问题。
敏感内容写入要区分“过滤”和“编码”
防 XSS、防注入这类需求，不是“删字符”，而是“上下文编码”：
- 写 HTML 文件？用
html.EscapeString，不是strings.ReplaceAll删 - 写 JSON？用
json.Marshal，别手动拼接字符串 - 写 SQL 参数？交给
database/sql的占位符，别自己strings.Replace转义单引号
混淆“过滤”和“编码”是线上事故高发区——前者删数据，后者保语义。比如把用户昵称 "O'Reilly" 过滤成 "OReilly" 是错的，正确做法是用参数化查询或 strconv.Quote 包裹。
