支持外链的网盘，历史链接清单缺少创建时间时怎样建立维护基线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc166bf011f0.html
📄
支持外链的网盘，历史链接清单缺少创建时间时怎样建立维护基线
缺少创建时间时，不要先补一个看似精确的日期，而应把“首次可确认状态”作为维护基线：以你当前能验证的链接状态、来源页和最近一次检查时间为锚点，再决定保留、改写还是退出。这样做的代价是基线晚于真实创建时间，但好处是后续每次检查都有可比较的依据，不会因猜测日期而误判链接老化程度。
先区分三种“缺时间”的原因，再决定补什么
历史清单没有创建时间，通常不是单一原因。第一种是导出字段缺失：清单只保留了文件名、分享地址和备注，时间字段在导出时被丢弃。第二种是链接经过改写或迁移，原始分享地址已被替换，旧时间随之失去对应关系。第三种是清单由多人拼接，早期记录只写了“已添加”，没有写日期。三种原因对应不同动作：字段缺失可以补“首次核验时间”；链接改写需要保留新旧地址的对应关系；多人拼接则要先确定唯一责任人，再统一基线口径。
如果无法区分原因，一个可用的判断方法是：看链接当前是否仍能打开，以及来源页是否仍指向它。能打开且来源页仍在，说明它至少还有当前价值；打不开但来源页仍在，说明需要判断是文件被替换还是分享设置失效；两者都失效，才进入退出候选。这个判断不依赖创建时间，因此适合作为临时基线。
保留：把“首次可确认状态”写成基线，而不是补日期
保留的前提是链接仍能访问，且来源页仍有访问价值。此时建议在清单中增加三列：首次核验日期、核验时的状态、核验人。首次核验日期就是你建立基线的当天，不要倒推。假设一份清单有 40 条链接，其中 12 条没有创建时间，你可以先对这 12 条做一次集中核验，把核验结果写进状态列。结果是：后续再出现失效时，你能区分“基线前就失效”和“基线后新失效”，而不是把所有问题混在一起。
保留的代价是基线偏晚。如果一条链接实际已存在很久，你却把它当作新链接维护，可能低估其老化风险。为降低这个代价，可以在备注中写“创建时间未知，首次核验于某日”，并给这类链接设置更短的检查间隔，例如先按季度检查，稳定后再放宽。
改写：只在不改变来源页意图时替换地址
改写适用于链接地址已变化、但来源页仍需要指向同一目标的情况。例如原分享地址因文件替换而失效，新地址指向同一份文件的最新版本。此时不要直接删除旧记录，而应保留旧地址、新地址、改写原因和改写日期。改写的条件是：来源页的上下文没有变，读者点过去仍能得到原本承诺的内容。如果来源页描述的是旧版本，而新地址指向新版本，改写就可能改变原意，这时应优先考虑退出或另建一条记录。
改写的一个实际动作是：先在来源页确认锚文本和周围文字是否仍与目标一致，再替换地址。如果锚文本写的是“某版本说明”，而新地址是通用下载页，替换后点击行为可能变化，下一步就应改为更新来源页文字，而不是继续沿用旧锚文本。这个动作的结果会直接影响你是否需要同步修改来源页，而不是只改清单。
退出：当链接既无法验证来源，也无法确认目标时
退出的条件比“打不开”更严格。若链接无法访问，同时来源页已被删除、改版或不再指向该链接，且没有其他页面引用它，那么继续维护的收益很低。此时可以从活跃清单移入历史归档，但不要直接删除记录。归档时保留原地址、最后可确认状态和移出日期，以便日后排查是否有人仍在使用。
需要说明的是，链接数量减少或某次抓取返回异常，并不能单独证明退出决定正确。服务器临时故障、分享权限短期调整、来源页改版都可能造成类似现象。因此退出前至少做一次跨时间复核：间隔一段时间再检查同一地址，并确认来源页状态。若两次结果一致，再执行归档。
建立可执行的最小基线
综合来看，缺少创建时间时，维护基线应包含以下字段：
- 链接地址与来源页地址
- 首次核验日期与核验人
- 核验时的状态（可访问、需改写、待退出）
- 若改写，记录旧地址、新地址与改写原因
- 若退出，记录移出日期与最后可确认状态
这套基线的取舍是：放弃追求真实创建时间，换取可重复检查的一致性。它适合历史清单已经混杂、无法逐一追溯的情况；如果清单规模很小且每条都能找到原始记录，仍应优先补真实时间。基线建立后，下一次维护只需比较状态变化，而不必重新争论日期。若你发现某条链接在两次核验之间从可访问变为需改写，就应优先检查来源页是否同步变化，再决定改写还是退出。
