土拨鼠日志：打包卡死不是包太大，是一个裸方括号

今天把土拨鼠的商用版 Windows 安装包从旧版本对齐到线上最新，再打成 .exe 上线官网。整个过程卡了三次，每一次都不是“代码写得差”，而是发布链路上那些最不起眼的小东西：一个裸方括号、一个目录权限、一个被替换成占位符的常量。这篇把三个坑原样摊开。

一、打包卡死，是一个裸方括号把语法检查干崩了

打安装包之前有一道“清洗闸”：把要出门的文件扫一遍，确认没有把敏感信息带出去。这步一直是个拦路的——它不是报“发现敏感信息”，而是直接崩在语法检查那里。

追到底，真凶让人哭笑不得：清洗脚本里有一段正则，里面混进了一个没有转义的裸方括号 [。正则引擎拿它去解析字符集区间，报了个 Range out of order，于是node --check 这关最先倒下，整条打包流程卡死在清洗步，后面再快的构建也轮不到跑。

修法就一处：把那个裸 [ 转义成 \[。语法恢复，清洗跑通，出门文件全部确认无硬机密。

这个坑值得记一条通用规矩：正则里的特殊字符，只要不是你要它“当语法用”，就一律转义。尤其当你的正则要“原样匹配”一段含括号、中括号、问号的字符串时，先检查有没有漏转义，再谈别的。

二、下载目录不给写，不是机器坏了，是属主不对

包打好了，238MB 多一点，要传到官网上给用户下载。传的时候又卡：目标目录写不进去。

排查下来不是网络、不是磁盘，是上级目录和子目录的权限不一致：外层目录可写，但下载那个子目录属主是运行站点的服务账号、权限是只读。

套路的解法也简单：先把文件传到可写的外层目录，再用提权命令挪进子目录、把属主和权限改对。上传完成后，本地和远端逐字节比对了哈希，一个字节都不差。

教训是：发布前端要先把“谁能写哪个目录”摸清楚，可写目录、只读目录分开记；别一遇到写不进去就先怀疑脚本。

三、脚本里的地址被批量换成了占位符

最隐蔽的是第三个：去翻一套老脚本，想复用里面的服务器地址，结果读出来是一个只有十几个字符的 [IP-REDACTED] 占位符——不是显示层遮蔽，是真的把文件里的内容替换掉了。

换成任何“看起来很合理”的前提都会带错路：要么硬编码一个可能过期的地址，要么照老脚本抄一个已经被抹掉的值。

定下来的规矩是：连服务器一律走域名，不去脚本里抄 IP。域名会跟着解析走，比抄一堆散落在各处的地址稳得多。

四、发布链路是一条链，断在哪都叫“没发成”

三个坑串起来，其实是同一件事的三段：清洗闸（语法）——目标目录（权限）——连接地址（占位符）。任何一段静默失效，对外表现都是同一句话：“脚本莫名其妙失败了”。

所以现在打一次包、发一次版，我们固定做四件事：

• 改前先备份，改完回读核对；
• 每个出门文件过一遍清洗闸，语法先自检；
• 上传后本地和远端比对哈希，不等于“传完就信”；
• 发布页上线后用公网地址再打一次，确认能下、能装。

想知道土拨鼠这套发布和巡检具体怎么落地，可以看 功能页；要算一笔自己跑的成本，定价页 有对照；想直接装一个试试就 下载，拿一件真事跑一遍，比看十篇介绍有用。

五、一个 30 秒自查

下次你发布卡住，按下顺序问自己三句：

• 是不是哪条正则里漏了个转义，把语法检查先干崩了？
• 目标目录的属主和权限，和你的账号对得上吗？
• 脚本里要连的地址，是不是已经被换成了占位符？

三个里中一个，多半就能解释“为什么打包发版老卡在中途”。发布不是慢在包大，是慢在那些没人愿意停下来看的小东西。