#部署包
该话题下聚合了社区中所有标记为「部署包」的公开帖子。
同一个部署包，我拿三台机子解压，解压顺序竟和文件大小有关
2026/11/8先说结论：解压顺序不是玄学，是文件系统在排序。 上周发版，部署包里有个 3G 的日志归档和一堆配置文件，用 Win解压缩 解压到共享盘，结果解压到一半卡在某个小文件上十几秒，进度条跟死了一样。我以为是磁盘 IO 问题，换了台机器还是一样。 实测环境： 机器 A：Win10 22H2，SATA SSD
日志包解压后ACL全丢，我拿三台机器对账，发现是解压时的权限选项没勾
2026/11/7上周处理一个线上故障，运维把日志包从跳板机拷下来，我解压后直接用 grep 搜关键字，结果提示一堆 Permission denied。一开始以为是压缩包本身有问题，后来 ls -l 一看，所有文件权限全是 644，原本的 640 和 600 全没了。 排查过程 我找了三个环境做对比： 本机 Win
部署包解压后权限全乱，我拿两台服务器对账，发现是解压工具没保留ACL
2026/11/6上周发版踩了个坑，记录一下，给同样用脚本解压部署包的兄弟提个醒。 场景：CI 流水线把构建产物打成 zip，传到目标机后由部署脚本自动解压。一直跑得好好的，结果这次上线后服务起不来，日志报权限拒绝。 排查过程： 先看文件权限，ls -l 一看，解压出来的可执行文件全变成了 644，原本应该是 755
部署包用7z还是zip？我拿三种工具实测了权限保留和增量更新
2026/11/6最近在整理 CI 的制品打包脚本，遇到个挺具体的问题：部署包用 7z 还是 zip，在 Linux 上解压后权限保留到底差多少？ 之前社区里聊解压速度的多，但权限这块没人细说，我干脆拿手头的日志包和部署包做了组对照。 测试环境 三台机器：Ubuntu 22.04（内核 5.15）、CentOS 7（
给部署包加权限校验，我比对四种压缩格式的元数据，结论有点意外
2026/11/5最近在搞部署包的权限校验，踩了个坑，记一笔。 背景：我们后端发版，部署包里混着可执行脚本和配置文件，权限位不对直接跑不起来。之前靠人肉 ls -l 核对，后来想着能不能在打包环节就把权限卡死，省得每次部署前还得手动查。 测试方法：拿同一个目录（含 755 脚本、644 配置、600 密钥文件），分别
部署包校验总对不上，我查了半天是WinRAR默认存了NTFS权限
2026/11/4上周发版，运维拿着我给的zip包解压后启动脚本报权限不足，我本地跑得好好的。第一反应是脚本路径写死了，查了半小时没毛病。 后来把两边的解压结果拉出来对账，才发现问题出在打包环节：我用的WinRAR 6.24，默认勾了「保存文件安全数据」，也就是把NTFS ACL一起塞进zip里。运维那边是Linux
部署包压缩格式选7z还是zip，我把解压耗时记了个表，结果和直觉不一样
2026/11/4平时给测试环境推部署包，包不大，200M 上下，一天推七八次是常事。一直默认往外发 zip，图个谁都能开。上周突发奇想，把同一份 dist 目录分别压成 tar.gz、7z 和 zip 三种，丢同一台机器上解压，拿秒表记了 10 轮取中位数，结果有点反直觉。 先说环境：Win10 22H2，i5-1
给部署包解压前后各跑一次校验，我把"文件顺序错乱"这事堵在源头
2026/11/2前阵子踩了个坑：解压一个部署包，解压软件报成功，结果启动时报找不到配置文件。目录结构看着对，文件名也对，就是内容串了——两个同名不同目录的配置被覆盖掉了一个。查了半天，问题不在软件，在我自己解压流程的先后依赖上。 说结论，先列点： 解压前先看包内清单，别直接全选拖出来。 我用 7-Zip 的 7z
解压出来的文件顺序全乱，我拿三个压缩包才搞清依赖问题
2026/11/1最近处理一批部署包，解压完发现文件顺序全乱，启动脚本直接报错找不到依赖。折腾了一下午，把踩坑过程记下来。 场景：一个 Spring Boot 项目的部署包，里面有 jar、配置文件、启动脚本，压缩时用了「存储」模式（不压缩），想着解压快。结果用 Win解压缩（版本 23.08）解压后，文件时间戳全变
部署包解压顺序乱了一次后，我给解压流程加了三道校验
2026/10/31上个月打包部署，踩了个不大不小的坑。 背景：我们的部署包结构是 config/ 下面按环境分目录，里面有个 application.properties 和一堆按模块拆的 .yml。打包脚本用 zip 扫目录，本来以为解压出来顺序无所谓，反正最后读的是合并后的配置。 结果在测试环境翻车了。某个模块的
解压部署包再压缩，我拿四个版本试了试文件头顺序还能不能保住
2026/10/31上周那篇日志按天拆分的帖子发出来后，评论区有人问了一句：如果解压出来再压回去，文件头顺序还在不在？我当时没测，这周抽空补上了。 场景很具体：我们后端部署包里有个日志目录，按天拆成 app-2024-06-01.log 到 app-2024-06-30.log，解压后要按日期顺序做校验。问题在于，从压
部署包解压到系统盘还是数据盘，我拿日志时间戳对了一遍才敢定规矩
2026/10/30最近连着处理几个模块的部署包，每个解压完 23G，临时目录默认在 C 盘，跑两天就红了。翻了翻解压缓存路径的帖子，发现大家都在聊删缓存，但没人说部署包解压位置的选择问题。我这边正好有日志时间戳可以拿来对账，说下实测结果。 场景：Jenkins 拉下来的 tar.gz 部署包，解压后要跑启动脚本。以前
部署包体积突然涨了200M，哈希对账揪出CI缓存没清
2026/10/28上周五发版，运维那边甩过来一句「包怎么又大了」，我一看构建产物，比上个版本多了 200M 出头。按老规矩，先别急着删东西，拿哈希对账。 先说环境 构建机：Jenkins 2.401，Ubuntu 22.04 打包脚本：自己写的 shell，tar.gz 走 tar -czf 对比工具：sha256s
拿哈希对账才发现，部署包里混进了三份全量日志
2026/10/28上周打包发版，运维那边反馈部署包从 400M 涨到了 1.2G，让我查查怎么回事。我第一反应是依赖又膨胀了，结果 du -sh 一看，最大的目录不是 nodemodules，是 logs/。 这事得从头说。我们部署包里本来只带一个启动脚本和几个配置文件，日志是运行时生成的。但上个月有个同事图省事，直
给日志包按项目分目录后，我拿哈希对账才发现上传脚本一直在重传全量
2026/10/28先说结论：日志和部署包体积失控，八成不是压缩算法的问题，是归档策略的问题。我这次踩的坑跟压缩软件本身没关系，纯纯是脚本逻辑。 背景 我们后端每天产出大约 4-6G 的日志包，加上每周两三次的部署包，之前全堆在一个目录里，按日期命名。最近发现备份盘吃紧，一查，三个月涨了 8 个 G 的增量，跟业务量根
拿20个部署包实测：Win解压缩批量解压快在哪，命令行又差在哪
2026/10/27最近手上要处理一批部署包，总共20个，每个300MB到1.5GB不等。正好借这个机会把Win解压缩和7-Zip的批量解压场景拉出来对了个账。先报版本：Win解压缩 3.2.1，7-Zip 24.08，系统Win11 23H2，SSD是SN770。 测试方法 20个zip包放在同一目录，用脚本分别调用
用脚本批量解压部署包，Win解压缩和7-Zip的耗时差我记了张表
2026/10/27最近赶上版本发布，手头堆了 300 多个部署包，单个 200MB 上下，全是 zip。正好拿这个场景把 Win解压缩和 7-Zip 在命令行下的表现对了一遍，数据如下，机器是 i7-12700 + 32G + NVMe，系统 Win11 23H2，Win解压缩 5.2.1，7-Zip 24.07。
部署包用Win解压缩命令行解压，居然比7-Zip慢了40%？我拿三台机子实测了
2026/10/26先说结论：之前我一直觉得 Win解压缩 命令行就是摆设，比不上 7-Zip。但最近公司部署流程要定工具，我拿三台机子（win10 22H2、win11 23H2、server 2019）各跑了 20 次，解压同一个 2.3G 的日志压缩包（内含 8000 多个小文件），结果有点意外。 实测数据： W
给部署脚本加了静默安装参数，结果三台机子装到一半卡住了
2026/10/25最近在搞批量部署，客户那边 80 多台机子要统一装一套内部工具链，Win解压缩、7-Zip、几个运行库，还有我们自己写的日志采集客户端。 先说结论：静默安装参数这东西，不能只看官方文档抄，得拿不同版本的安装包实测，而且得看它会不会跟已装组件打架。 踩坑过程 我一开始图省事，直接拿 /S 和 /qui
部署包解压后中文文件名变问号，我翻出打包机的系统区域设置才搞定
2026/10/25上周发版遇到个邪门事：同一个部署包，在我 Win11 开发机解压正常，到 CentOS 测试机就一堆 ??? 文件名，日志目录直接找不着。 现象 包是 CI 上打的 zip，文件名含中文 本地用 Win解压缩 6.8 解压正常，用 7-Zip 24.09 也正常 scp 到 Linux 用 unzi
拿Win解压缩和7-Zip压同一批部署包，命令行这块我认栽了
2026/10/22先说结论：Win解压缩解压速度确实快，但命令行支持不如7-Zip，日常点鼠标的人用它没问题，像我这种要靠脚本批量处理部署包和日志的，最后还是得把7-Zip当主力。 背景是上周要发一个版本，部署包里有300多个文件、大小1.2G，另外还有一坨按天切的日志（每天一个压缩包，一共14个）。我拿两台机器（一
部署包里的空目录老丢，我查了半天是打包工具默认跳过
2026/10/22上周发版，一个 Java 服务起不来，报错说日志目录不存在。我本地跑得好好的，一查部署包，logs/ 这个空目录没了。 先说环境：CentOS 7.9，JDK 11.0.15，打包用 Maven assembly 3.3.0，解压是运维那边直接 tar -xzf。 排查过程列一下： 先看 Maven