#后端开发
该话题下聚合了社区中所有标记为「后端开发」的公开帖子。
部署包解压后文件时间全变，我拿两台机器对账才发现是保留了目录时间戳
2026/11/8前两天发版出岔子，我第一反应是代码有问题，结果查了半天是解压部署包时文件时间全被改了，排错方向从一开始就跑偏了。 现象 场景很普通：CI 打了个 tar.gz 部署包，我在测试机解压后跑启动脚本，日志里几个模块加载顺序不对。运维说看文件时间能判断哪个是新包，我一看，所有文件修改时间都是解压那一刻，跟
给20台机器批量装软件，我写了个清单脚本，版本号精确到构建号
2026/11/5公司最近要统一办公软件环境，IT 让我帮忙出个清单脚本。我一开始觉得不就是 winget list 导个表，结果一跑发现版本号太糙，同一款软件在不同机器上显示一样，实际构建号差了七八个。 我的做法是： 用 PowerShell 读注册表 Uninstall 键，把 DisplayName 和 Dis
批量改部署包文件名，我写了脚本跑两百次才敢推
2026/11/4先说结论：文件重命名这种活儿，手动改三个五个还行，上百个部署包就是自找麻烦。我上周接了个活，要把一批日志压缩包按「日期服务名序号」重命名，总共两百多个，挨个改到第三天我直接写了脚本。 场景：运维丢过来一个目录，里面是近半年的服务日志压缩包，文件名乱七八糟，有带时间戳的、有带主机名的、还有俩重名的。要
给200台机子装软件，静默参数抠了三天，发现MSI和EXE要分开伺候
2026/11/2这两天接了个活，给分公司200台机子批量装软件，有内部工具也有第三方客户端。本来以为写好脚本一把梭就行，结果光静默安装参数就抠了三天，踩的坑比预想多得多。 先说结论：MSI 和 EXE 要分开处理，参数不能混用，更不能信网上抄来的万能模板。 我分了三台机子做对照测试：Win10 22H2、Win11
给部署包解压前后各跑一次校验，我把"文件顺序错乱"这事堵在源头
2026/11/2前阵子踩了个坑：解压一个部署包，解压软件报成功，结果启动时报找不到配置文件。目录结构看着对，文件名也对，就是内容串了——两个同名不同目录的配置被覆盖掉了一个。查了半天，问题不在软件，在我自己解压流程的先后依赖上。 说结论，先列点： 解压前先看包内清单，别直接全选拖出来。 我用 7-Zip 的 7z
解压软件把临时文件塞系统盘，我改了缓存路径后C盘多出12G
2026/10/30前几天 C 盘又报警，只剩 800M。我第一反应是日志包堆多了，结果 du 一跑，发现 %TEMP% 下面躺着十几个 .tmp 文件夹，加起来 12G 多。 查了下时间戳，全是解压大包时留下的。Win解压缩 默认把临时文件放系统盘，解一个 2G 的部署包，峰值能占到 4-5G，解完还不一定立刻清。
给部署脚本加了静默安装参数，结果三台机子装到一半卡住了
2026/10/25最近在搞批量部署，客户那边 80 多台机子要统一装一套内部工具链，Win解压缩、7-Zip、几个运行库，还有我们自己写的日志采集客户端。 先说结论：静默安装参数这东西，不能只看官方文档抄，得拿不同版本的安装包实测，而且得看它会不会跟已装组件打架。 踩坑过程 我一开始图省事，直接拿 /S 和 /qui
部署包在服务器上解压慢三分钟，我查了半天发现是文件系统这块拖后腿
2026/10/23上周发版遇到个怪事，同一批部署包（大概 1.2G，里头几十个日志和 jar），在本地 NVMe 盘上解压 40 秒搞定，丢到测试服务器上解压了三分半。一开始我怀疑是 Win解压缩 的锅，毕竟版本不一样，结果换了 7-Zip 命令行也一样慢，那就得往别处找了。 先报环境： 本地：Win10 22H2，
把Win解压缩塞进批处理脚本，我踩了三个坑才搞明白它不支持管道
2026/10/19昨天想偷个懒，把日志压缩包的解压流程写成批处理，结果在Win解压缩上直接卡住了。 背景：每天要处理几十个部署包，手动右键解压太慢，想写个脚本循环调用命令行。之前用 7-Zip 的 7z x 跑得好好的，想着 Win解压缩 速度确实快，试试能不能替上。 测试环境：Win10 22H2、Win11 23