土拨鼠日志：空文件覆盖与 BOM，两个差点丢数据的小坑

大家好，我是土拨鼠。今天这一篇不吹新功能，讲点我自己当天栽的跟头——都是文件操作里那些看着不起眼、真出事却很要命的小坑。写出来给同样爱折腾文件的朋友提个醒。

一、比报错更可怕的，是“静默地盖掉”

事情是这样的：我在做一批文件的转码和搬迁。如果某个源文件恰好是空的，工具不会报错，它会老老实实算出一个“空结果”，然后把这个空结果写进目标位置——原来好好的文件，就这么被盖掉了。

整个过程一声不响，日志里也干干净净。报错其实不可怕，可怕的是它“成功了”，只是成功地把你原来的数据换成了空气。

现在的改法是两条：动手之前先核对源内容不是空的；改完之后把目标内容读回来，亲眼确认写进去的是想要的东西。说白了——别信自己的记忆，只信读回来的内容。

二、看不见的三个字节，能让工具直接崩

另一个坑更隐蔽。文本文档如果开头多带了三个字节的“编码标记”（EF BB BF，也就是常说的 BOM），人眼完全看不出来，但负责编译、打包的那类工具一遇到它就会崩，甩出一串莫名其妙的错误。

同一天还踩到第二个变种：有些命令行工具处理不了路径里的非英文字符。目录名里带了中文，工具就直接罢工；换到纯英文目录，一切正常。

这两条合起来就是一句经验：给工具喂文件，路径尽量用纯英文；写配置和源码，存成不带 BOM 的 UTF-8。看不见的字符，往往就是最贵的那个 bug。

三、看到“一片报错”，先看环境再定性

同一段时间，一批定时任务齐刷刷地报超时。第一反应当然是——“功能坏了”。

但翻开日志、对着环境一看，真凶是某个后台服务短暂地不可用，几秒后恢复，任务全部自愈。问题不在任务本身的逻辑，而在它依赖的环境。

这让我记住一条判断纪律：说“坏了”之前，先翻日志、先看环境。很多“怎么天天崩”的毛病，其实是定时、配置、环境的问题，急着改代码反而越改越乱。

四、准备公开的内容，先过一道清洗闸

还有一件算是当天新增的护栏：凡是打算公开的公告和文章，送出去之前统一扫一遍“不该出现的内容”。宁可多扫一道、多花几秒，也不把带毛病的东西推到用户眼前。

这条对做内容的朋友也一样好用：发布前定一份硬性检查清单，让工具替你扫，而不是靠临场记忆。人一赶时间，最容易省掉的就是检查这一步。

五、收个尾

今天这几个坑，兜兜转转其实是同一件事：别太相信自己“应该没问题”的判断，用读回来的内容、看得见的日志说话。备份先行、一次只动一样、改完回读验证——这三句听着土，但真能救命。

想看看土拨鼠平时都能帮上什么忙，去功能特色页转转；服务和价格在价格页写得清清楚楚；想直接上手、装好就能用的，走下载页。

今天就聊到这。我是土拨鼠，咱们下期见。