企业官网建设流程全解析

上线一个服务，团队会拉群、发公告、开庆功会；下线一个服务，往往没人愿意签字。真正做过系统重构的人都有体会：加代码容易，删代码难；把一个跑了几年的老模块从架构里摘干净，比新写一个模块更考验工程能力。很多事故不是发生在"上线新功能"的那一刻，而是发生在"旧链路以为没人用了，悄悄关掉"的那一天。

这就是本文要聊的事：当一段技术关系走到尽头——老服务要退役、旧依赖要解耦、遗留系统要迁移、某个技术栈要退出历史舞台——怎么处理才算"智慧"。核心判断先说在前面：优雅下线的能力，是区分"能写代码"和"能维护系统"的分水岭。它考验的不是编码技巧，而是盘点、灰度、观测、回滚这四件事的工程化程度。

如果你正在经历下面任何一种场景，这篇文章值得从头看到尾：手上有个说不清谁在调用的老接口准备关停；团队要把单体拆成微服务，需要把耦合的模块切开；公司要求某个中间件、某个框架版本限期下线；或者你接手的项目里躺着一堆"不敢删、不知道干什么用"的定时任务和配置项。

下面的内容会按"为什么难 → 概念边界 → 前置准备 → 六步流程 → 代码实现 → 效果验证 → 排错 → 工程建议"的顺序展开，每个步骤都给出可以照着做的命令、配置和代码，最后附一份退役检查清单，方便你直接拿去改造成自己团队的模板。

1. 这篇文章真正要解决的问题

先厘清一个常见误解。很多人以为"下线一个服务"就是运维层面把进程停掉、把域名解析删掉、把代码仓库归档。如果只看表面，这确实是一分钟的事。但真正容易踩坑的地方在于：一个运行了两三年的服务，它的调用方从来不在你的架构图里。

架构图画的是主链路，实际存在的调用方往往是这些：某个同事三个月前写的临时脚本、BI 团队的一个定时拉数任务、另一个业务线复制粘贴过去的 SDK、一条没人记得的 MQ 消费、一个报表系统的离线同步、甚至是一个已经离职同事留下的 cron。它们不会出现在任何文档里，但会在你把服务关掉的第 37 分钟集中爆发。

所以这个问题的本质不是"删除"，而是依赖关系的发现与收敛。它解决的是工程协作层面的认知缺口：团队对自己系统的真实边界不清楚，导致任何一次"减法"操作都带着不可控风险。这也解释了为什么很多团队宁可让老服务继续跑着烧钱，也不敢关——不是不想关，是关不起。

本文面向的读者很具体：正在负责系统重构、服务治理、技术栈升级的中高级后端工程师和架构师；需要为下线决策拍板的技术负责人；以及刚接手遗留项目、被要求"清理一下"但不知道从哪下手的新同学。前置知识要求不高，能看懂 HTTP 调用、数据库读写、配置中心的基本用法就够了。

2. 核心概念与适用场景

在动手之前，需要先把几个容易混淆的概念分清楚。很多团队推进不下去，不是技术难，而是讨论的时候各说各的。

这里最容易被误解的是"依赖解耦"。不少团队的做法是把http://old-api/xxx改成http://new-api/xxx，然后在文档里写一句"已完成解耦"。这不是解耦，这是换了个地址，耦合关系一点没变，只是被推迟了。真正的解耦发生在契约层：调用方依赖的是稳定的接口语义和数据格式，而不是某个具体实现的存在。

另一个需要说清楚的概念是兼容期。退役不是二元的"开/关"，而是一个有时间窗口的过渡状态。在兼容期内，新旧两套链路同时存在，新链路承接增量，旧链路只做兜底，靠开关和灰度逐步把流量挪过去。这个窗口的长度取决于调用方的数量、它们能否配合改造成本，以及数据是否需要双向同步。经验上，内部服务之间三到六个月是常见区间，跨团队、跨系统、涉及外部合作方的场景会更长，具体要按实际情况评估，不要拍脑袋定一个"两周搞定"。

至于适用场景，可以按复杂度分三档。第一档是单团队内部的工具类服务，调用方两三个，直接谈好时间点就能关。第二档是跨团队的业务服务，需要走灰度、需要兼容期、需要对账。第三档是平台级基础设施，涉及计费、权限、数据合规，除了技术方案还要走流程审批和法务确认。这三档的做法差异很大，把第三档当第一档处理，基本等于埋雷。

3. 环境准备与前置条件

动手之前，先把"作战地图"准备好。这一步做扎实，后面能省掉大量返工。本文的示例以常见的 Java 后端加 Python 脚本配合为主，版本请以你实际项目为准，重点看思路和流程，不要把版本号当成硬约束。

需要准备的东西分四类：

• 代码可达：能扫描到所有相关仓库，包括已经"半废弃"但还在跑的分支。很多隐性调用就藏在长期无人维护的仓库里。
• 流量可见：网关或接入层能按来源、按接口、按调用方维度出报表。如果没有，先去补埋点，否则后面的灰度就是盲飞。
• 配置可控：有统一的配置中心或至少能动态下发开关，能做到不发版就改行为。降级、双写、灰度比例这些都需要动态开关支撑。
• 观测具备：调用链追踪（TraceID 贯穿）、错误率、延迟分位、QPS 四类指标要能查历史。判断"旧链路是否真的没人用了"，靠的就是这些历史数据，而不是问一圈同事。

工具方面，命令行的grep、ripgrep和代码仓库的全局搜索是基础；如果有多仓库场景，建议搭一个轻量的扫描脚本；数据库侧需要能执行只读查询和导出；网关侧需要能配置路由规则和按比例分流。

这里有个前置条件特别容易被忽略：先冻结新增调用。在开始盘点的同一天，就应该在文档、代码评审规范、接口平台上标注"该接口已进入退役流程，禁止新增调用"。否则你一边在收敛，一边有人在新增，永远收不完。这个动作成本极低，收益极高，但很多团队就是不做，导致项目拖成烂尾。

4. 核心流程拆解：六步走完一次"体面分手"

整个流程可以拆成六步，顺序不能乱。跳过任何一步都会在后面以事故的形式补回来。

4.1 第一步：盘点，把隐性调用方挖出来

盘点不是翻架构图，而是"用数据和代码说话"。三个来源交叉验证：代码扫描、网关日志、注册中心与配置中心。

代码扫描解决"谁在代码里写了调用"，网关日志解决"谁在运行期真的在调"，注册中心和配置中心解决"有没有连接和配置残留"。三者对不上很正常，对不上的部分才是重点——比如代码里删了但流量还在，说明有外部系统在调；流量没有但配置还在，说明有潜在的定时任务。

这一步的产出应该是一张清单：调用方名称、负责人、调用量、调用方式（同步/异步）、是否有数据读取、计划改造时间。没有负责人的调用方，优先级反而最高，因为没人认领意味着没人会改。

4.2 第二步：冻结，堵住新增入口

在接口平台、网关、代码仓库三个层面同时标注下线中状态。网关层面可以对新增的调用方直接返回告警或拒绝，代码层面在评审清单里加一条"是否新增对退役服务的依赖"。

这一步的目的是把"拍水"和"放水"分开。收敛过程中的任何新增依赖，都会让原本的时间表失去意义。

4.3 第三步：兼容，建新链路并保证语义一致

新链路上线时，最容易被低估的是语义差异。旧接口可能返回null，新接口返回空集合；旧接口的分页从 1 开始，新接口从 0 开始；旧接口的错误码是 200 加业务码，新接口直接用 HTTP 状态码。这些差异不会在联调阶段暴露，会在灰度到 30% 的时候集中爆出来。

所以兼容阶段要做两件事：一是契约对齐，把字段含义、边界值、错误语义逐条比对并落到文档；二是双写或影子读，在不影响主流程的前提下，让新链路同步跑一遍，比对结果。比对不是看有没有报错，而是看数据是否一致，差异率要能统计出来。

4.4 第四步：灰度，按比例把流量挪过去

灰度的单位要选对。按百分比随机分流适合流量大、无状态的服务；按用户 ID 或租户 ID 分桶适合有状态、需要连续体验的场景；按调用方维度切分适合 B 端接口。三种方式经常组合使用。

关键动作是先把旧链路降级为兜底，再把新链路设为主路，而不是相反。顺序反了，一旦新链路出问题，你连一个已知可用的退路都没有。

灰度比例建议 1% → 5% → 20% → 50% → 100%，每一档至少观察一个完整的业务周期。如果你的业务有明显的高峰低谷，观察窗口要覆盖高峰，否则等于没观察。

4.5 第五步：摘除，关停旧链路并保留回滚

流量到 100% 之后不要立刻删代码，先进入观察期。观察期内旧接口返回 410 或明确的停用提示，监控上专门盯"是否有请求打到已停用接口"这条指标。这条指标归零并稳定一段时间，才算真正没人用了。

回滚方案要在关停之前就写清楚：配置开关怎么翻回去、数据怎么补偿、服务怎么重新拉起、多久能恢复。没有回滚方案的下线，本质上是一次豪赌。

4.6 第六步：清理，代码、配置、数据、权限一起收尾

这一步最容易被跳过，也最容易留下技术债。需要清理的清单包括：代码仓库（归档并标注墓碑）、网关路由、配置中心条目、注册中心实例、定时任务、MQ 队列与消费组、数据库表与索引、对象存储桶、证书、监控告警规则、权限账号、文档入口。

其中数据库和存储的处理要特别谨慎。删除是不可逆操作，规范做法是先归档到历史库或冷存储，保留一份只读快照，设定保留期限，到期后再走正式的删除审批。涉及用户数据的，还要符合内部的合规要求，这一点必须提前和相关部门确认，不要自行决定。

5. 完整示例与代码实现

下面给出一套可以直接跑起来的最小实现，覆盖盘点、开关灰度、双写校验和下线验证四个环节。示例是通用的工程思路，实际项目里按自己的技术栈替换即可。

5.1 依赖盘点脚本：把调用方扫出来

这段脚本扫描指定目录下的代码文件，匹配目标服务的域名、SDK 类名和包名，输出一份带文件路径和行号的清单，方便逐个确认负责人。

# 文件路径：scripts/scan_dependency.py import json import re from pathlib import Path # 需要识别的旧服务特征，按实际项目替换 TARGET_PATTERNS = [ re.compile(r"https?://legacy-api\.example\.com"), re.compile(r"LegacyUserClient"), re.compile(r"import\s+com\.example\.legacy\."), re.compile(r"legacy[_-]?user[_-]?service", re.IGNORECASE), ] # 只扫描这些后缀，避免把二进制和日志扫进来 SCAN_SUFFIXES = {".java", ".kt", ".py", ".go", ".js", ".ts", ".yaml", ".yml", ".properties", ".xml"} # 这些目录直接跳过，通常是构建产物或依赖缓存 SKIP_DIRS = {"target", "build", "node_modules", ".git", "dist", "vendor"} def scan(root: str) -> list: hits = [] base = Path(root).resolve() for path in base.rglob("*"): if not path.is_file(): continue if path.suffix not in SCAN_SUFFIXES: continue if any(part in SKIP_DIRS for part in path.parts): continue try: text = path.read_text(encoding="utf-8", errors="ignore") except OSError: continue for lineno, line in enumerate(text.splitlines(), start=1): stripped = line.strip() # 跳过纯注释行，减少噪音 if stripped.startswith(("#", "//", "*", "<!--")): continue for pattern in TARGET_PATTERNS: if pattern.search(line): hits.append({ "file": str(path.relative_to(base)), "line": lineno, "pattern": pattern.pattern, "code": stripped[:160], }) break return hits if __name__ == "__main__": import sys target = sys.argv[1] if len(sys.argv) > 1 else "." results = scan(target) print(f"命中 {len(results)} 处引用") print(json.dumps(results, ensure_ascii=False, indent=2))

运行方式和预期输出：

python3 scripts/scan_dependency.py ./src

脚本会打印命中数量和明细 JSON。命中数量多不可怕，可怕的是命中之后没人认领。实际使用时，建议把输出按仓库或目录聚合，再结合代码仓库的 blame 信息找到最近修改人，逐个确认。注意这个脚本只扫描静态代码，编译期的依赖注入、反射调用、配置驱动的调用扫不出来，必须配合网关日志一起看。

5.2 动态开关与灰度路由配置

灰度一定要靠动态配置驱动，不能靠发版。下面是一个配置中心侧的开关结构示例，字段含义在代码注释里说明。

# 文件路径：config/legacy-user-migration.yaml switch: # 总开关，false 时全部走旧链路，用于紧急回滚 enabled: true # 新链路流量比例，取值 0-100，灰度时按 1/5/20/50/100 逐步调整 new_chain_percent: 5 # 强制走新链路的调用方白名单，用于内部先把自家服务切过去 force_new_chain: - order-service - payment-service # 强制走旧链路的调用方黑名单，优先级高于白名单 force_old_chain: - report-batch-job # 旧链路返回给未迁移调用方的提示，便于排查是否是漏改 legacy_warning_header: "X-Legacy-Api-Deprecated" # 双写比对模式：off / log / block # off 关闭，log 只记录差异不阻断，block 差异时直接报错（仅建议测试环境使用） dual_write_mode: log

对应的分流逻辑要实现成"确定性分桶"，而不是每次请求随机。随机分桶会导致同一个用户在不同请求间反复横跳，行为不稳定，排查时也难以复现。用调用方标识或用户标识做哈希取模，才能保证同一个来源始终落在同一侧。

// 文件路径：src/main/java/com/example/migration/GrayRouter.java package com.example.migration; import java.util.List; import java.util.zip.CRC32; public class GrayRouter { private final boolean enabled; private final int newChainPercent; private final List<String> forceNewChain; private final List<String> forceOldChain; public GrayRouter(boolean enabled, int newChainPercent, List<String> forceNewChain, List<String> forceOldChain) { this.enabled = enabled; this.newChainPercent = newChainPercent; this.forceNewChain = forceNewChain; this.forceOldChain = forceOldChain; } /** * @param caller 调用方标识，优先使用调用方而非用户，便于按系统维度灰度 * @param bucketKey 分桶键，没有调用方标识时用用户 ID 兜底 * @return true 表示走新链路 */ public boolean useNewChain(String caller, String bucketKey) { if (!enabled) { return false; } if (caller != null && forceOldChain.contains(caller)) { return false; } if (caller != null && forceNewChain.contains(caller)) { return true; } if (newChainPercent <= 0) { return false; } if (newChainPercent >= 100) { return true; } return hashBucket(bucketKey) < newChainPercent; } private int hashBucket(String key) { if (key == null) { key = "unknown"; } CRC32 crc32 = new CRC32(); crc32.update(key.getBytes(java.nio.charset.StandardCharsets.UTF_8)); return (int) (Math.floorMod(crc32.getValue(), 100)); } }

这段代码的关键点有三个。第一，黑名单优先级高于白名单，因为黑名单通常是"已知有问题的调用方"，必须优先保护。第二，用 CRC32 取模而不是随机数，保证同一个 key 的分桶结果稳定，方便复现问题。第三，开关关闭时直接返回旧链路，这样回滚只需要改一个配置值，不需要发版。

5.3 双写与结果比对

双写的目的是在不改变对外行为的前提下，验证新链路的结果是否和旧链路一致。要点是：新链路的调用必须异步、限流、不影响主流程，任何异常都要吞掉并记录，绝不能因为比对逻辑把主业务搞挂。

// 文件路径：src/main/java/com/example/migration/DualWriteComparator.java package com.example.migration; import java.util.Objects; import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicLong; public class DualWriteComparator { private static final ThreadPoolExecutor POOL = new ThreadPoolExecutor( 2, 4, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(2000), r -> { Thread t = new Thread(r, "dual-write-cmp"); t.setDaemon(true); return t; }, new ThreadPoolExecutor.DiscardPolicy() // 队列满了直接丢弃，绝不阻塞主流程 ); private static final AtomicLong TOTAL = new AtomicLong(); private static final AtomicLong DIFF = new AtomicLong(); /** * @param mode off / log / block * @param key 业务主键，用于定位差异 * @param oldVal 旧链路结果 * @param newFunc 新链路调用，注意内部要做超时控制 */ public static void compare(String mode, String key, Object oldVal, java.util.function.Supplier<Object> newFunc) { if ("off".equals(mode)) { return; } TOTAL.incrementAndGet(); POOL.execute(() -> { try { Object newVal = newFunc.get(); if (!Objects.equals(String.valueOf(oldVal), String.valueOf(newVal))) { DIFF.incrementAndGet(); // 这里接你的日志组件，打印主键和两侧结果，便于抽样核对 System.err.printf("[DIFF] key=%s old=%s new=%s%n", key, oldVal, newVal); if ("block".equals(mode)) { throw new IllegalStateException("双写比对不一致: " + key); } } } catch (Exception e) { // 比对失败不影响主流程，只记录 System.err.printf("[CMP-ERROR] key=%s err=%s%n", key, e.getMessage()); } }); } public static String stats() { long total = TOTAL.get(); long diff = DIFF.get(); double rate = total == 0 ? 0 : diff * 100.0 / total; return String.format("total=%d diff=%d rate=%.4f%%", total, diff, rate); } }

调用位置放在业务逻辑返回之前，用主键做 key，把旧结果传进去，新链路用 lambda 延迟执行。差异率这条线要接到监控上，正常情况下应该在灰度前几天快速下降到接近零，如果长期维持在某个固定值不降，说明是语义差异而不是偶发问题，必须回去改契约，不要靠"再观察观察"糊过去。

5.4 下线验证脚本

关停之前跑一遍验证清单，比关停之后亡羊补牢便宜得多。下面这个脚本检查几个最常见的残留：接口是否还有请求、域名是否还能解析、配置项是否还在被读取。

#!/usr/bin/env bash # 文件路径：scripts/pre_shutdown_check.sh set -uo pipefail LEGACY_HOST="legacy-api.example.com" LEGACY_PATH="/api/v1/user/profile" GATEWAY_LOG="/var/log/gateway/access.log" WINDOW_MINUTES=60 FAIL=0 echo "== 1. 检查最近 ${WINDOW_MINUTES} 分钟是否仍有请求 ==" RECENT=$(grep -F "${LEGACY_PATH}" "${GATEWAY_LOG}" 2>/dev/null \ | awk -v cutoff="$(date -d "-${WINDOW_MINUTES} minutes" '+%Y-%m-%dT%H:%M')" \ '$0 ~ /\[/ { print }' | tail -n 20 || true) if [ -n "${RECENT}" ]; then echo "[WARN] 窗口期内仍检测到请求，样例：" echo "${RECENT}" FAIL=1 else echo "[OK] 窗口期内无请求" fi echo "== 2. 检查动态配置中心残留 ==" if command -v curl >/dev/null 2>&1; then CODE=$(curl -s -o /dev/null -w '%{http_code}' \ "http://config-center.example.com/api/item?key=legacy.user.enabled" || echo "000") if [ "${CODE}" = "200" ]; then echo "[WARN] 配置项仍未删除，HTTP ${CODE}" FAIL=1 else echo "[OK] 配置项已清理或不可达，HTTP ${CODE}" fi fi echo "== 3. 汇总 ==" if [ "${FAIL}" -eq 0 ]; then echo "全部检查通过，可以进入关停审批" exit 0 else echo "存在未通过项，请先处理再关停" exit 1 fi

这个脚本里的日志格式和配置中心地址都得换成你自己的，date -d在 macOS 上行为不一致，跨平台使用时建议换成 Python 或明确指定实现。脚本的价值不在于它多完美，而在于它把"拍脑袋决定"变成了"跑一遍再说"，并且可以放进发布流程里做自动化卡点。

6. 运行结果与效果验证

验证分三个层次，缺一个都不能算完成。

第一层是静态验证。盘点脚本跑完，命中清单里的每一行都有负责人和处置结论，没有"待定"。这一层的判断标准很朴素：清单上不允许出现"未知"。

第二层是行为验证。灰度期间，新旧两条链路的成功率、P99 延迟、错误码分布要能对比。这里有个判断技巧：不要只看新链路的指标绝对值，要看它相对旧链路的增量。新链路比旧链路慢 20ms 在有些系统里完全可以接受，在交易链路上就不可接受，阈值要提前定好，而不是出问题之后再找理由。

第三层是收尾验证。旧接口停用后，专门盯一条指标：打到已停用接口的请求数和来源。这个数应该快速归零并稳定一段时间。如果它一直是零星的个位数，大概率是某个低频定时任务，可能一天只跑一次，观察窗口至少覆盖一个完整的调度周期，日任务看三天，周任务看两周。

验证通过后的预期状态可以这样确认：

# 期望返回 404 或 410，而不是 500 或超时 curl -s -o /dev/null -w '%{http_code}\n' \ "http://legacy-api.example.com/api/v1/user/profile" # 期望配置项已不存在 curl -s "http://config-center.example.com/api/item?key=legacy.user.enabled" # 期望注册中心里已无该实例 curl -s "http://nacos.example.com/nacos/v1/ns/instance/list?serviceName=legacy-user"

如果返回 500 或超时，说明服务还在跑但已经处于异常状态，这比返回 410 更危险，因为调用方可能还在重试，形成雪崩。第一步应该看网关的错误率和上游超时日志，而不是去翻业务代码。

7. 常见问题与排查思路

下面这张表是实践中最常遇到的坑，按出现频率排序。每一条都对应前面流程里的某一步没做扎实。

这张表里最值得单独说的是第一条。很多团队关停之后发现还有请求，第一反应是"有人偷偷在用"，实际上更常见的是自己的离线任务。判断方法很简单：看请求的时间分布。如果集中在凌晨某个固定时刻，基本就是定时任务；如果均匀分布在业务高峰，那就是线上调用方漏改。

8. 最佳实践与工程建议

流程跑通一次不难，难的是让"优雅下线"成为团队的常规能力。下面几条是从长期维护角度给出的建议。

第一，退役要有正式文档，而不是群里的口头约定。一份合格的退役说明至少包含：退役原因、影响范围、调用方清单及负责人、时间表、兼容期长度、回滚方案、数据处置方式、联系入口。这份文档的价值在于，半年后有人问"这个服务为什么没了"，能有一个确定的答案，而不是靠回忆。文档本身也要留一个永久入口，不要跟着服务一起删掉。

第二，把观察期写进流程，不要靠自觉。关停之后设置一段强制观察期，期间旧接口返回明确的停用提示而不是直接 404。这个提示里可以带上替代接口地址和负责人联系方式，能省掉大量"这个接口怎么不能用了"的询问。

第三，监控和告警要在关停之前处理。服务停了，告警规则还在，就会持续产生误报，最后大家把告警静音，连带把真正的问题也静音了。正确顺序是：先停业务流量，再调低告警阈值或直接停用规则，最后删服务，中间的每一步都记录在案。

第四，数据处置必须走审批，不要技术侧单方面决定。涉及用户数据、交易数据、日志数据时，保留期限、归档位置、访问权限都要和相关部门确认。技术上可以做冷热分离、可以压缩归档，但"能不能删、什么时候删"不是工程师一个人能定的。这一条看起来和代码无关，但它是很多团队在合规检查时被卡住的地方。

第五，给团队留一套可复用的模板。把本文的六步流程、检查清单、脚本改造成自己团队的模板，放进内部文档库。下一次退役时，从"要不要做"直接跳到"按模板执行"，这才是真正的效率提升。模板里最容易遗漏的是"权限与账号"和"监控规则"两项，建议单独列成小节，避免每次都要重新想。

第六，灰度比例和时间窗口要留够余量。计划两周完成的灰度，实际往往需要一个月，因为总会有调用方在第三周才回复消息。排期时按实际需要的两倍估算，比事后解释为什么延期要轻松得多。

9. 一个可以直接拿去用的退役检查清单

把前面所有内容压缩成一份清单，建议在退役启动会上逐条过一遍，关停前再逐条确认一遍。

启动前必须确认：调用方清单是否完整、每个调用方是否有明确负责人、是否已在接口平台标注下线中、是否已禁止新增调用、兼容期长度是否经过各方确认、回滚方案是否演练过、数据处置方式是否通过审批。

灰度阶段必须确认：开关是否支持不发版调整、分桶是否确定性、双写是否异步且不影响主流程、差异率是否有监控、是否覆盖了业务高峰、每一步灰度的观察时长是否记录在案。

关停前必须确认：停用验证脚本是否全部通过、观察窗口是否覆盖完整调度周期、告警规则是否已调整、旧版本镜像保留期是否延长、权限账号是否已回收、文档是否已归档、是否有面向调用方的停用说明。

关停后必须确认：停用接口访问量是否归零、数据库连接是否回收、MQ 队列与消费组是否清理、配置项是否删除、注册中心实例是否下线、域名与证书是否处理、监控与日志是否停止采集、归档数据是否可查。

最后想说一句判断：技术上的"分手"和人际关系里的道理其实是相通的——体面不在于说得多好听，而在于把对方的后续安排想清楚，并且给彼此留好退路。一个服务下线时，调用方能不能平滑迁移、数据能不能随时回查、出问题能不能快速回滚，这三件事做好了，才叫真的处理得智慧。下次再遇到要关停的老系统，别急着执行删除命令，先把这份清单拿出来走一遍。