周五下午，我接到一个任务：核实高炉系统和烧结系统的数据库及点位对接信息。打开终端探了一下内网业务节点的常用端口，全部 TCP 超时------远程接入工具没登录，内网完全不通。没法连库查数据，没法跑脚本验证。只能翻配置文件。
这不是最理想的状态，但也不能就此停工。下面记录一下我实际怎么做、踩了什么坑、最后报告里怎么写。
内网全断：先划清取证边界
内网不通时，所有结论只能来自静态文件。我列了四台内网节点（两台业务节点、一台外部 MES 节点）的常用端口，逐一 TCP 探测，全部超时。远程接入工具未登录，短时间内也连不上。
这意味着几件事我必须写进报告开头：
- 数据库里实际存了什么数据、点位是否真的在采集、Redis 里有没有热缓存，这些我完全看不到。
- 我能看到的只有：连接串指向哪个节点、哪个库、哪个 db 编号、鉴权用的哪个实例。
- 任何涉及"运行时状态"的结论，都不能由我出具。
在报告第一行就标注"内网全断，以下结论基于静态配置文件与初始化脚本原文，未经运行时验证"，读者才知道该给这些结论打几折。跳过这一步，后面写再多细节都白搭。
配置文件逐行取证：yml 里藏着什么
高炉系统的业务配置在 ironmaking-server 模块的 application-dev.yml 里，烧结系统在 ironmaking-sj-server 的同名文件中。我逐段读了两个文件，把每个连接信息标上行号，方便同事复核。
高炉侧，我在 yml 里定位到以下连接配置：
- 业务库：内网 A 节点 3306 端口，库名
iron（yml 第 4-6 行） - 业务 Redis：同节点 6380 端口，db 编号 4（第 26-30 行）
- 鉴权 Redis：内网 B 节点 6379 端口，db 编号 11（第 91-98 行）
- IoTDB 时序库：A 节点 6667 端口（第 36-41 行）
- 外部 MES 库：10 段地址 3306 端口，库名
tqts，账号为独立业务用户（第 78-83 行） - Socket 通信：A 节点 8191 端口（第 52-56 行）
烧结侧文件结构类似，但有一个关键发现------它的业务库连接串指向和高炉完全相同：同一个 iron 库、同一个 3306 端口。区别只在 Redis 的 db 编号和 IoTDB 的表前缀上。
两个系统共用一个库：最容易漏的坑
这一点如果靠"猜"，大概率会漏掉。
高炉和烧结在业务上是两个独立模块，前端页面分开部署，运维同学习惯性地认为它们各有各的库。但配置文件原文写得很清楚：烧结服务连的业务库就是 iron，和高炉共用。两者通过 Redis 不同 db 编号、IoTDB 不同表前缀来隔离数据。
这个发现直接影响了后续操作的风险评估。任何数据库迁移、主从切换、权限变更，都必须同时拉两个服务的影响面。我把这条写进了报告的"风险提示"栏，并附了两个模块的 yml 原文截图，避免下游同事只看一个模块就动手。
初始化 SQL 和 Java 常量：补充证据链
光看 yml 不够。我翻了项目根目录 init_sql/ 文件夹，里面有两张关键表：
- 点位映射表：把 DCS 点位编号映射到业务字段名，约 180 条记录。
- 系统字典表：枚举炉型、烧结工艺参数等。
Java 代码里有个 PointConstant.java，硬编码了 200 多个点位编号，注释里标了每个点位对应的物理量（炉顶压力、风口温度、烧结料温等）。我拿这些编号和 SQL 映射表做了交叉比对，记录是对得上的。
但因为内网不通，我无法确认这些点位在 DCS 侧是否真的在采集、数据是否落库。报告里我逐条标注了"基于代码常量，未经运行时验证"，没有替它们背书。
三条可以带走的经验
-
先声明取证边界，再写结论。 网络不通就是不通，别假装验证过连通性。报告第一句话写清楚证据来源和局限，读者才知道该给结论打几折信任。
-
配置文件加行号，结论才可追溯。 每个连接信息都标注 yml 行号（比如
:4-6、:26-30），同事拿到报告可以直接sed -n '4,6p'定位原文，不用重新翻文件。报告的价值不在于"我查了"，而在于"你五秒内能验证我查的"。 -
别假设"一个系统一个库"。 共用库在遗留项目里太常见了。做数据库变更前，
grep一下所有模块的application*.yml，把连接串拉出来放一张表里横向对比，比问运维靠谱得多。
做自动化这几年，最耗时间的从来不是写代码，是摸清每个平台的脾气。
这篇里提到的坑，都是真金白银踩出来的。 这篇里的场景你踩过类似的吗？是卡在「需求说不清」还是「改完就崩」？ 评论区说说，我按最多人卡的点接着写。