产品化第一版：Linux安装包是怎么炼成的
系列第18篇 | AI探索历程 | 把"半年配置"装进一个zip
一、目标：一个zip搞定一切
一键部署的想法确定后，首要目标先落地Linux版本。
目标很简单：用户拿到一个zip压缩包，解压，运行安装脚本，即可完成整套环境部署，无需手动安装任何依赖。
我把过去半年一步步踩坑搭出来的整套环境全部打包：
- Python 3.11 虚拟环境（venv）
- Node.js运行时
- OpenClaw核心程序
- 自动化安装脚本
- 配套卸载脚本
一句话：把半年的配置工作量，全部打包塞进一个zip文件。
二、坑1：zip存不住Linux文件权限
第一个难题很快就撞上。
打包完成，本地测试一切正常。但换到新机器执行启动脚本，直接抛出：Permission denied。
排查后才发现：zip压缩格式不会保留Unix文件权限位。
打包机器上脚本权限是755可执行，解压到新服务器后自动变成644，只能读取，无法运行。
最终解决方案：安装脚本遍历所有bin目录，批量补全文件可执行权限。
zip能压缩文件，却带不走Linux的权限。
三、坑2：venv的"思乡病"
权限问题修复，Python虚拟环境又直接报错崩溃：
Fatal Python error: init_fs_encoding...
根因：虚拟环境配置文件pyvenv.cfg里的home字段，还写着打包机器上的Python绝对路径。
迁移到新服务器后，venv找不到原来的路径，就像得了思乡病，直接无法启动。
解决方案：安装阶段自动重写pyvenv.cfg中的home路径，指向当前部署位置的Python。
venv并不是完全自包含的，它会记住打包机器上的"家"。
四、坑3：logs目录凭空"失踪"
好不容易解决虚拟环境问题，服务依旧无法访问页面，提示连接被拒绝。
想查看日志排查，结果日志文件根本不存在。
根源：启动脚本用了 nohup python web_server.py > logs/web.log，脚本没有预先创建logs文件夹。shell重定向输出失败，Web服务根本没有启动，但脚本还在打印"已启动"的提示，造成假象。
解决方案：在启动脚本开头增加 mkdir -p logs，自动创建日志目录。
脚本输出的"启动成功"，不等于服务真的正常运行。
五、坑4：sudo交互导致脚本卡死
切换到非root账号测试，新问题出现。安装脚本自动安装Node.js时需要sudo权限，脚本没有处理交互式密码输入，进程直接卡在原地，看上去像死机。
解决方案：检测当前运行身份，如果是非root用户且需要sudo，给出明确提示；长远方案则尽量内置运行时，减少对系统sudo的依赖。
六、一个zip包正式诞生
踩完这四个大坑，Linux一键安装包终于稳定可用。
用户操作流程：解压 → 执行 bash install.sh → 确认协议等待安装完成 → 运行 bash start.sh → 打开网页，录入业务需求。
半年的调试配置，最后简化成两行命令。
一键部署的价值，不在于技术多么炫酷。
而是把复杂留给自己，把简单留给用户。