★ FEATURED ARTICLE 1. 先说说为什么要给一个旧版本单独建下载仓库上周有个做教学直播的朋友半夜发消息说他那套用了两年的插件在升级后全部罢工问我能不能找到OBS Studio 28.1.2 版本的安装包。我翻了半天官方页面只挂最新版旧版本要么散落在各种第三方下载站里要么就是被重新打包过、塞了不知道什么东西的安装器。这件事之后我干脆花了一个周末把 OBS Studio 28.1.2 版本下载仓库从零搭了起来——不是简单地扔几个安装包到网盘里而是一套带清单、带校验、带状态标记、可长期维护的版本归档站。这篇文章就是把整个过程拆开讲清楚仓库怎么设计目录、文件怎么命名、清单怎么定字段、校验怎么做、发布层要注意哪些 HTTP 细节、后续怎么自动化巡检。如果你也在维护某个软件的版本归档或者只是单纯需要一个升级出事了能退回去的保险位这套方法基本可以直接照搬。即使你现在只是想去下一个 OBS Studio 28.1.2 的安装包看完也能自己判断哪个来源靠谱、哪个包里可能有问题。1.1 版本号里那三个数字各管一段命很多人看版本号就是一个整体其实28.1.2这三个数字各有分工理解了这个分工你才知道为什么偏偏是这个版本需要被单独归档。第一个数字28是大版本号它决定的是插件接口、脚本 API、配置文件格式这一层。大版本一动之前编译好的插件大概率要重新编译配置文件也可能会被迁移。我在社区的反馈里看到28 分支确实动过一轮插件接口也抬高过系统版本门槛这就解释了为什么一批人升上去之后发现常用的老插件变成了灰色不可用。中间那个1是功能更新号通常带来新特性和行为变化不会打破插件接口但可能改变默认参数。第三个2是修订号只修 bug不引入新东西。所以28.1.2的定位就很清楚了它是28这条线上修到比较干净的状态、又不引入新变化的点。对生产环境来说这种大版本末期 修订号靠后的组合往往是稳定性最好的一档。这也是我选择拿它作为归档重点、而不是随便挑一个旧版本的原因。1.2 真实场景里到底谁在找这个版本我把身边用这个版本的人归了归类大概是这么几类。第一类是插件生态被卡住的。有人靠某个特定插件吃饭那个插件在 28 之后就没人维护了升级意味着工作流直接断掉。这类人不是不想升级是升不起。第二类是硬件老旧的。老机器、老显卡驱动、老系统新版本对硬件门槛的要求会让它直接跑不起来或者卡成幻灯片。录音棚、教室的多媒体机、还有那种专门用来做长时间录制的备用机都属于这一类。第三类是复现需求的。比如某门课给的工程文件、某个项目要求的录像参数是基于特定版本的行为写的换个版本可能编码器表现就不一样最后录出来的码率、关键帧间隔对不上。这种情况你必须锁版本不是择优。第四类是纯粹做归档的。有些团队对用了什么工具、什么版本、什么时候装的有记录要求旧版本得留着能查、能重装。这四类需求有一个共同点他们要的不是最新的功能而是确定的、可复现的那一个。这就决定了版本仓库的设计目标——第一是可信第二是稳定可达第三才是好用。顺序不能反。1.3 仓库的边界只归档绝不二次打包这条必须写在最前面因为它是整个仓库能不能被人信任的分水岭。我见过太多所谓下载站把原始安装包解出来、换个图标、加个启动器、绑个推广组件再重新压回去。体积大了几十兆哈希当然也对不上官方公布的任何值。这种做法一旦混进版本归档里整个仓库的可信度就归零了。我的原则是三条原样归档、保留原始哈希、不碰二进制。文件名可以按规范重命名但重命名这个动作本身不能改变文件内容——这点要清楚改名不影响 SHA-256。所有清单里的哈希值必须是文件落盘时算出来的真实值而不是从别处抄来的。注意如果你打算把别人的版本归档再分发出去一定核对原始文件哈希不要信任任何中间环节转录的字符串。一个字符抄错用户校验就会失败然后开始怀疑整个仓库。2. 仓库的整体设计目录、命名与清单整套仓库其实就三样东西一堆按版本分目录的文件、一个描述这些文件的清单、一个给人看的入口页面。看起来简陋但每一项都有讲究尤其是命名和清单字段前期省事后期就要还债。2.1 目录结构怎么定才经得起版本变多我的目录结构是这么排的obs-archive/ ├── index.html # 入口页人看的 ├── manifest.json # 全量清单程序看的 ├── SHA256SUMS # 顶层汇总校验文件 ├── 28.1.2/ │ ├── obs-studio-28.1.2-windows-x64-installer.exe │ ├── obs-studio-28.1.2-windows-x64-portable.zip │ ├── obs-studio-28.1.2-macos-arm64.dmg │ ├── obs-studio-28.1.2-macos-x86_64.dmg │ ├── obs-studio-28.1.2-linux-ubuntu2204-x86_64.deb │ └── SHA256SUMS ├── 28.1.1/ │ └── ... └── _assets/ └── style.css几个关键决定值得说一下。版本号做一级目录且直接就是28.1.2这种裸版本号不搞v28/v28.1/v28.1.2三级嵌套。原因很现实用户拿到一个版本号最直接的路径拼接就是/版本号/文件名层级一多你就得在页面里维护一堆映射关系还容易错。每个版本目录里自己带一份SHA256SUMS顶层再放一份汇总的。这不是冗余——单版本目录里那份是给我只想校验这一个版本的几个文件的人用的顶层那份是给我要整体镜像这个仓的人用的。两种使用场景两种粒度都留着更省事。_assets用下划线开头是为了在按字母排序时排到最前面同时和版本号目录在视觉上区分开避免有人误以为assets是个版本号。2.2 文件命名规范别小看这一条命名这件事我在做第一版的时候随手写的结果后面写脚本、写清单、配缓存规则的时候被反复恶心。后来定了一套硬规矩反例正例原因OBS Studio 28.1.2 (64bit).exeobs-studio-28.1.2-windows-x64-installer.exe空格和括号在 URL 里要转义命令行里要引号脚本里极易出错OBS-28.1.2-setup.exeobs-studio-28.1.2-windows-x64-installer.exesetup语义模糊installer明确是安装型obs_28_1_2_win.zipobs-studio-28.1.2-windows-x64-portable.zip下划线分隔和点号版本混用正则匹配变得痛苦obs-28.1.2-win.exeobs-studio-28.1.2-windows-x86_64-installer.exewin/x64不够精确32 位和 ARM 平台上容易撞名格式固定为{产品名}-{版本号}-{平台}-{架构}-{类型}.{扩展名}。产品名全小写连字符版本号保留原始点号形式与官方发布一致平台用windows/macos/linux全称别用win/mac架构用x64/x86_64/arm64按各平台习惯但同一平台内部必须统一类型区分installer安装型、portable免安装、appimage、deb、rpm等。提示规范命名之后原始文件名一定要记进清单里。有些用户在别处看到过原始文件名来你这里找不到就会以为不是同一个包。清单里加一个original_name字段能省掉大量解释成本。2.3 清单文件设计给机器看的契约manifest.json是整个仓库的核心。它决定了别人能不能写脚本自动同步、能不能程序化判断某个版本还在不在、能不能自动挑出适合自己平台的包。我的字段设计是这样的{ product: obs-studio, archive_version: 2, generated_at: 2024-05-01T08:12:33Z, versions: [ { version: 28.1.2, status: eol, channel: stable, release_guess: 2023-01, important: 28 分支末期修订版改动集中于稳定性修复, files: [ { name: obs-studio-28.1.2-windows-x64-installer.exe, original_name: OBS-Studio-28.1.2-Full-Installer-x64.exe, platform: windows, arch: x64, kind: installer, size: 118446080, sha256: 3f9c...完整 64 位十六进制, path: /28.1.2/obs-studio-28.1.2-windows-x64-installer.exe } ] } ] }几个字段值得单独解释。status用active/eol/yanked三档。eol是不再维护但可用yanked是发现问题、不建议使用。这个字段的价值在于你可以明确告诉用户我知道它旧我也知道它还能用而不是含糊地把所有旧版本平铺在一起让人猜。archive_version是仓库自身的结构版本号不是软件版本。哪天你调整了字段结构加个版本号能让你自己在脚本里做兼容分支。size一定要填且单位是字节。这个字段是排查下载问题最快的锚点——用户说下下来不对第一句就是让他看字节数。path用绝对路径别搞相对路径。相对路径在页面、脚本、CDN 三种上下文里含义可能不一样绝对路径只有一种解释。2.4 入口页面要交代清楚的三件事页面不需要花哨但必须回答三个问题这是什么版本、它还能不能用、下完怎么验。我的页面上每个版本一行状态用文字标不用颜色色弱用户看不见旁边放文件列表和对应的 SHA-256 前 16 位。完整哈希点开单文件详情才显示避免页面太长。页面顶部固定一段说明这个仓库只做原始安装包的归档分发不做二次打包不捆绑任何东西所有哈希为落盘实算值。页面底部放一段如何校验把三个平台的命令都贴出来直接复制就能用。这段说明看着像废话但实际上它是整个仓库可信度的证据。用户来下旧版本本来就带着戒心你主动把校验方法摆在明面上而不是藏在三级菜单里这个动作本身就是一种筛选。3. 从零搭建的完整流程设计讲完进入动手环节。这一节我把命令和脚本都写全你按顺序跑一遍就能得到一个能用的仓库。3.1 环境和工具准备需要的工具不多都是常见货色。# 基础工具检查 for c in curl wget python3 jq sha256sum find; do command -v $c /dev/null echo OK $c || echo MISS $c donecurl用来拉取python3跑校验和清单生成脚本jq在命令行里读改 JSONsha256sum算哈希find做目录遍历。Windows 上如果没有这些用 WSL 或者直接在 Linux 容器里跑脚本产出物再同步上去比在 Windows 上折腾兼容性省事得多。存储侧我建议用对象存储或者静态托管别用会执行脚本的托管环境。原因很简单这个仓库里全是二进制文件和静态 JSON引入脚本执行能力只会增加攻击面没有任何收益。3.2 抓取归档与生成校验和归档这一步的关键是落盘就跑哈希中间不给人手改的机会。我写了个半自动的流程先把文件人肉放到_incoming/目录然后跑脚本搬到正式位置、算哈希、更新清单。#!/usr/bin/env bash # archive.sh —— 把一个版本的文件归档入库 set -euo pipefail VER28.1.2 ROOT$(cd $(dirname $0) pwd) INCOMING$ROOT/_incoming TARGET$ROOT/$VER mkdir -p $TARGET # 1. 搬运并校验命名合规小写、连字符、无空格 for f in $INCOMING/*; do base$(basename $f) if [[ $base ~ [[:space:]\(\)] ]]; then echo 命名不合规请先改名: $base 2 exit 1 fi mv -n $f $TARGET/ done # 2. 生成该版本目录的校验文件 cd $TARGET sha256sum * SHA256SUMS echo --- $VER 校验文件 --- cat SHA256SUMSset -euo pipefail这三件套必须加。归档这种批处理脚本一旦中间某步失败却不中断后面的清单就会基于残缺状态生成那是最危险的情况——清单看起来正常实际少文件或者哈希对不上。命名合规检查那段是我后来补的因为吃过亏。有一次从上游拉下来的文件名里带了一对括号在全流程里一路无事直到配缓存规则时正则匹配不上排查了两个小时。3.3 清单生成脚本这一步把目录里的实际文件翻译成manifest.json。核心思路是文件系统是唯一事实来源清单是它的映射。不要反过来手写清单再生成文件那是倒过来的迟早不一致。#!/usr/bin/env python3 # gen_manifest.py —— 基于目录实际内容重建清单 import hashlib, json, os, re, sys from datetime import datetime, timezone ROOT os.path.dirname(os.path.abspath(__file__)) VER_RE re.compile(r^\d\.\d\.\d$) # 元数据放在独立文件里手维护不混进自动生成逻辑 with open(os.path.join(ROOT, _meta.json), encodingutf-8) as fp: META json.load(fp) def sha256_of(path, chunk1 20): h hashlib.sha256() with open(path, rb) as fp: while True: b fp.read(chunk) if not b: break h.update(b) return h.hexdigest() def parse_name(name): # 产品-版本-平台-架构-类型.ext stem, _, ext name.rpartition(.) parts stem.split(-) if len(parts) 5: return None return { platform: parts[-3], arch: parts[-2], kind: parts[-1], } versions [] for entry in sorted(os.listdir(ROOT)): vdir os.path.join(ROOT, entry) if not os.path.isdir(vdir) or not VER_RE.match(entry): continue files [] for fname in sorted(os.listdir(vdir)): fpath os.path.join(vdir, fname) if not os.path.isfile(fpath) or fname SHA256SUMS: continue info parse_name(fname) if info is None: print(f跳过无法解析的文件名: {fname}, filesys.stderr) continue files.append({ name: fname, original_name: META.get(entry, {}).get(origin, {}).get(fname, ), platform: info[platform], arch: info[arch], kind: info[kind], size: os.path.getsize(fpath), sha256: sha256_of(fpath), path: f/{entry}/{fname}, }) versions.append({ version: entry, status: META.get(entry, {}).get(status, eol), channel: META.get(entry, {}).get(channel, stable), important: META.get(entry, {}).get(important, ), files: files, }) manifest { product: obs-studio, archive_version: 2, generated_at: datetime.now(timezone.utc).strftime(%Y-%m-%dT%H:%M:%SZ), versions: sorted(versions, keylambda v: [int(x) for x in v[version].split(.)], reverseTrue), } out os.path.join(ROOT, manifest.json) with open(out, w, encodingutf-8) as fp: json.dump(manifest, fp, ensure_asciiFalse, indent2) print(f已生成 {out}共 {len(versions)} 个版本)这段脚本有个设计选择值得说把人工维护的元数据和自动生成的清单分开。_meta.json里只放那些机器判断不出来的东西——版本状态、重要说明、原始文件名对应关系。清单本身每次全量重建。这样做的好处是你永远不会遇到清单里写的是 A磁盘上是 B这种矛盾。清单是派生物磁盘是本体派生物随时能重建。3.4 发布层的三个配置细节文件放上去只是开始能不能下得顺全看发布层配置。这三个细节我踩过坑逐个说。第一Content-Type 必须按扩展名正确设置。很多对象存储的默认行为是把.exe当成application/octet-stream甚至更糟——当成文本类型浏览器直接打开一堆乱码。.dmg、.zip、.deb同理。配置片段大概长这样# 缓存层配置示意 location ~* \.(exe|zip|dmg|deb|msi)$ { default_type application/octet-stream; add_header Content-Disposition attachment; add_header X-Content-Type-Options nosniff; } location ~* \.(json|html|css)$ { default_type application/json; # html/css 各自对应 add_header Cache-Control no-cache; }注意这两段缓存策略是反的二进制包可以长时间缓存因为它们内容永不变但manifest.json和页面必须不缓存或者短缓存否则你更新了清单用户看到的还是旧的然后拿着旧哈希去校验新文件当然失败。第二必须支持 Range 请求。一百多兆的安装包用户网络一抖动就得从头下体验极差。断点续传依赖的是 HTTP 的Range头如果你前面套了一层自己写的转发逻辑或者做了全量缓冲这个能力就没了。验证方法很简单curl -r 0-1023 -o /dev/null -w %{http_code} %{size_download}\n \ https://你的域名/28.1.2/obs-studio-28.1.2-windows-x64-installer.exe返回206且下载字节数是1024说明 Range 生效。返回200就是没生效。第三清单和文件要同源同域。别把manifest.json放一个域名、文件放另一个域名。一是跨域麻烦二是用户看到两个域名天然会怀疑。归档站最重要的是看起来就是一个整的东西。3.5 自动巡检把链接失效这件事掐死在前面仓库最怕的不是没人访问是有人访问了但下不下来。所以我加了一个每周跑一次的巡检脚本。#!/usr/bin/env bash # healthcheck.sh —— 校验清单与实际文件一致性 可达性 set -uo pipefail BASEhttps://你的域名 FAILED0 while IFS$\t read -r path size sha; do url${BASE}${path} # 1. HEAD 探测可达性 code$(curl -sS -o /dev/null -w %{http_code} -I --max-time 20 $url) if [[ $code ! 200 ]]; then echo 不可达 [$code] $path FAILED1 continue fi # 2. 比对远端 Content-Length 与清单 size remote_size$(curl -sSI --max-time 20 $url \ | awk tolower($1)content-length:{print $20} | tail -1) if [[ $remote_size ! $size ]]; then echo 体积不符 期望:$size 实际:$remote_size $path FAILED1 fi done (jq -r .versions[].files[] | [.path, .size, .sha256] | tsv manifest.json) [[ $FAILED -eq 0 ]] echo 全部通过 || { echo 存在异常请处理; exit 1; }这个脚本只做 HEAD 探测和体积比对不做全量哈希下载——全量算一遍要几百兆流量没必要每周跑。真正需要验哈希的时候是用户报问题的时候那时候人工跑一次就够了。FAILED标志位和退出码是为了能挂到定时任务里报警。定时任务不报警等于没做这是我在别的事情上吃过亏才记住的。4. 校验与可信度别让好仓库变成风险点仓库建起来之后最大的风险不是技术问题而是信任问题。一个旧版本下载站天然带着你是不是干过什么的质疑。这一节讲怎么用可验证的方式回应这个质疑。4.1 SHA-256 和官方签名是两个层级的事很多人以为算了 SHA-256 就万事大吉其实它是两个层级。SHA-256 解决的是传输完整性你下的这个东西和我归档的那个东西是不是同一个字节序列。它防的是网络传输损坏、存储介质静默错误、下载软件拼接错误。官方签名解决的是来源真实性我归档的这个东西是不是官方发布的那个东西。Windows 上安装包有数字签名macOS 上应用包有代码签名和公证Linux 上部分仓库有 GPG 签名。这两件事不能互相替代。一个恶意改过的包可以有一个完全正确的 SHA-256——那个哈希是重新算的只是它对应的内容不对。所以正确的顺序是先验来源再验完整性。实操上Windows 用户拿到.exe之后右键属性看数字签名那一栏签名者是不是产品方这是第一道然后用清单里的 SHA-256 比对这是第二道。两道都过才能算放心。4.2 三个平台的校验命令直接抄这部分我在页面上原样贴了因为很多人卡在知道要校验但不会敲命令。WindowsPowerShellGet-FileHash -Algorithm SHA256 .\obs-studio-28.1.2-windows-x64-installer.exe | Format-List老系统上只有 CMD 的话certutil -hashfile obs-studio-28.1.2-windows-x64-installer.exe SHA256macOSshasum -a 256 obs-studio-28.1.2-macos-arm64.dmgLinuxsha256sum obs-studio-28.1.2-linux-ubuntu2204-x86_64.deb批量校验更省事把SHA256SUMS和文件放同一目录sha256sum -c SHA256SUMS输出一串OK就全对出现FAILED就说明那个文件有问题——先重下那一个别急着重下全部。注意sha256sum -c对文件名的匹配是严格的包括大小写和空格。如果你从网页上复制文件名的时候带了个全角空格它会报找不到文件而不是校验失败。这两个报错含义完全不同别看串了。4.3 macOS 上那个已损坏提示大概率不是真损坏这一条必须单独讲因为它是咨询量最大的问题。用户在 macOS 上双击.dmg或者打开应用弹窗说应用已损坏建议移到废纸篓。九成以上不是文件坏了是 Gatekeeper 的隔离属性在起作用——从网络下载的文件会被打上一个扩展属性标记系统对没有公证链或者公证链不被当前系统认识的包会用这个措辞提示。先验哈希。哈希对得上说明文件本身没问题那就是隔离属性的事。移除隔离属性的命令是xattr -dr com.apple.quarantine /Applications/OBS-Studio.app但我得说清楚这个命令关掉的是系统的一道安全提醒不是修复。执行之前你必须已经通过哈希校验和来源确认确定这个包是你信任的。如果是来路不明的包哈希对不上那提示可能就是在救你。提示清理隔离属性只应该是确认安全之后的操作不能当成遇到提示就执行的万能键。这个顺序反了风险是实打实的。4.4 版本真伪的几个旁证除了哈希和签名还有几个细节能帮你判断一个包是不是原样文件体积。安装型和免安装型体积差别很大同类型同平台的包体积应该在一个合理区间。如果一个 Windows x64 安装包只有十几兆那基本不可能是完整的。文件时间戳。归档时我保留了原始修改时间用户能看到这个包大概是哪个时期的东西。如果时间戳是昨天而版本号是三年前的那就有问题。清单里的original_name字段。这个字段能对上说明归档链路没被人插过手。5. 常见问题排查实录这一节把我这几个月收到的咨询和踩过的坑整理成速查形式。很多问题看着五花八门归到底就那么几类。5.1 下载类问题先看字节数下载出问题第一反应永远是比对字节数这一步能砍掉一半的排查路径。现象最可能的原因处理方式下载完成但打不开体积明显偏小下载被中断浏览器当成完成换支持断点续传的工具重下比对size字段体积比清单大一点下载工具自动加了附加内容或者下到了错误文件用原始哈希比对不匹配直接重下下载到 99% 卡住不动服务端 Range 支持不完整或中间层有缓冲换下载器加--retry参数浏览器里点链接变成一堆乱码服务端 Content-Type 配错修正为application/octet-stream并加attachment下载速度忽快忽慢缓存层和源站策略不一致统一缓存 TTL避免半途回源有一点要强调体积对得上不等于内容对得上。体积只能过滤掉最粗的错误真正的判定还是哈希。我遇到过体积完全一致但内容不同的情况——那是下载工具在多线程拼接时段边界算错了很少见但存在。5.2 安装与运行类问题分清是包的问题还是环境的问题用户说装不上或者装上了打不开先分清这两件事。装不上多半是包的问题或者系统门槛问题。系统版本不够、架构装错把 arm64 的包装到 x86 上、磁盘空间不足、权限不够这几条占绝大多数。装上了打不开多半是环境问题。显卡驱动太老导致编码器初始化失败、运行库缺失、插件冲突、配置文件从高版本带过来不兼容。这一类最典型的症状是启动画面一闪就退或者启动后主界面能出来但一开录制就崩。我的排查顺序是先看日志再怀疑插件最后怀疑驱动。日志目录各平台不一样但都在用户配置目录下里面会明确写是哪个模块初始化失败。插件冲突有个很省事的验证方法临时把插件目录改名。改名之后能正常启动就锁定是插件的事再一个个往回加二分法定位。这比逐个卸载重装快得多。配置文件不兼容也常见。从高版本退到低版本时配置文件里可能有低版本不认识的新字段轻则参数丢失重则启动崩溃。稳妥做法是退版本之前先把配置目录整个备份一份然后让低版本自己生成一份干净的配置需要什么再手动调。别指望配置文件能双向兼容它基本只能单向升级。5.3 版本选择类问题别盲目追旧来问旧版本的人里有一部分其实不该用旧版本只是被某个具体问题卡住了。如果问题是插件不兼容先花十分钟确认插件是不是真的没有新版本。有些插件作者只是换了发布渠道不是停更。如果问题是性能不够旧版本未必更快。大版本在编码器调用上往往有优化回退可能更卡。如果问题是硬件跑不动新版本那退版本是对的选择但要注意旧版本在安全更新上已经停了别把它放在暴露环境里长期跑。我的判断标准是能通过换配置、换插件、换驱动解决的问题不要靠退版本来解决。退版本是最后一张牌打出去就意味着放弃了后续所有修复。6. 长期维护的几个经验仓库建起来容易养下去难。这几个月下来有几条经验我觉得比技术细节更值得说。6.1 版本淘汰要有明确规则不能凭感觉我最开始的做法是都留着反正一个版本也就几百兆。但很快问题就来了页面越来越长用户翻半天找不到自己要的反而增加困惑。后来定了规则只保留当前主线大版本的前后各一个小版本加上被明确标记为生产推荐的那一两个。其余的移到冷存储页面上只留一行更早版本请联系维护者并且清单里保留哈希记录。这个规则的好处是把删除变成下沉用户不会觉得东西凭空消失了只是取用成本变高了一点。同时清单里的哈希永远留着哪天有人需要核对历史文件查得到。冷存储那份我建议做成一个单独的归档包按年份打包附带当年那份manifest.json。这样即使主线仓库全丢了历史记录还有一份完整快照。6.2 我踩过的几个具体的坑坑一改了文件名但忘了重算清单。有个文件我发现命名里少了个架构标识随手重命名忘了重跑gen_manifest.py。结果清单里的path指向一个不存在的文件巡检脚本报错我一开始还以为是被误删了。后来给脚本加了发现清单和磁盘不一致就直接失败的检查再没犯过。这个检查很便宜就是重建之后比对一遍但能省掉一整轮排查。坑二缓存 TTL 设得太长把清单也缓存了。更新版本之后我自己访问是新的因为浏览器强刷但用户那边一直看到旧清单导致校验值对不上。排查了半天才想到是这个原因。现在manifest.json走no-cache二进制文件走长缓存井水不犯河水。坑三把体积当成了唯一校验手段。早期页面上只写了文件大小没写哈希。有个用户下载后打不开我让他比对大小对得上就以为是他的环境问题来回折腾了很久。后来让他算哈希才发现内容不对——多线程下载器拼接错误。从那以后页面上哈希是必须项前 16 位直接展示不给用户省略的选项。坑四没给旧版本标注状态。有个版本我后来发现有问题但不方便直接删除有人已经在用了。当时页面上就是平铺展示没有状态标记导致新用户还会去选那个有问题的版本。后来加了status字段yanked的版本会在文件名旁边加一行醒目说明并且在清单里标出来。归档站的责任不只是提供文件还有提供判断依据。6.3 一个我觉得值得坚持的小做法每次更新仓库我都会在页面顶部留一行变更记录就一句话什么时候、加了什么、为什么。不写摘要不写背景就一句事实。这行记录最初只是为了给我自己看后来发现用户也会看。有人专门来找这个版本是什么时候加进来的因为这能帮他判断这个归档是不是还在活跃维护。一个半年没动过的归档站和一个每周都有人整理的归档站可信度完全不一样。维护这件事本身就是可信度的一部分。文件放在那里不会说话但更新记录会。最后分享一个我一直在用的检查习惯每次有人反馈下载问题我先让他把文件名、字节数、哈希前 8 位贴出来这三项一贴问题基本就定位到一半了。这个小流程我给不少人说过用起来确实省事——比来回问你用的什么浏览器你网络怎么样高效太多。
阅读完成 · 觉得有帮助？
