一个本地 WMS 实例的 JDBC 配置明确指向测试数据库，但登录用户、权限和部分页面行为却像来自另一套环境。单看配置文件，很容易得出“应用偷偷连错数据库”的结论。

排查后发现，同一个 Web 应用同时依赖多种数据来源；这些来源指向不同环境，造成了看似数据库串线的现象：

• 业务数据通过 JDBC 访问数据库；
• 登录、用户和权限通过远程 UPM 服务取得；
• Dubbo 服务地址由注册中心或缓存决定；
• Redis 保存会话、权限或服务发现相关缓存；
• 本机还可能同时运行多个 Tomcat，每个实例加载不同的配置目录。

因此，业务列表来自测试库，并不代表权限也来自测试环境。

先确认真正处理请求的进程 …

一台仓库 RF 设备连续打印多张包裹标签时，经常在中途停住。相同打印机从电脑端使用基本正常，因此最初很容易把问题归因到模板、打印机缓存或 Android 代码。

真正有用的证据来自三处：应用发送日志、打印任务的张数位置，以及 RF 到打印机的网络质量。日志显示前几张标签已经完成 TCP 连接和写入，下一张却在连接阶段超时；同时 RF 侧出现明显丢包，而电脑侧连接仍然稳定。问题源于热点链路在打印机处理任务时短暂不可连接，某张标签的内容并未损坏。

为什么一次发送整批数据不可靠

原实现把多张标签拼成一个较大的字节流，通过一次连接全部写入。这个方式代码简单，但现场链路一旦抖动，就很难判断打印机已经接收 …

一个 WMS 波次计划列表查询一页数据需要约 6 秒。这篇文章记录实际排查路径：从应用日志拿到真实 SQL，检查现有索引，测试并回退无效索引，最后验证新的 SQL 执行结构。

文中的环境和业务标识均已脱敏，SQL 结构、耗时数据和判断过程来自实际排查。

慢查询的执行结构

页面需要查询波次主表，关联明细与出库单，聚合 OMS 订单号和 Homebase，关联创建人、修改人信息，并查询装车时间，最后按创建时间倒序返回 50 条。

日志中的关键筛选条件是修改时间范围、组织和项目条件，同时按照创建时间排序。

问题就在这里：SQL 在确定页面最终需要的 50 个波次前，已经开始展开明细、聚合并排序。

先 …

物流系统中的小 Bug 经常反复出现，不一定是规则没有写，而是规则只写在某个按钮、页面或异常分支里，没有覆盖真正改变业务状态和数据的入口。

下面四类缺陷来自不同功能，但中心问题相同：业务规则必须放到真正改变状态或数据的共同操作中，并让所有入口返回一致的处理结果。

编辑权限必须约束动作，而不只是按钮

费用详情只允许在 NEW 或 REJECTED 状态编辑。页面隐藏了部分按钮，但表格事件仍能打开编辑框，导致已经进入财务流程的数据存在被修改的风险。

修复不能停在视觉层。编辑动作的统一入口必须先检查状态，后端也需要拒绝越权更新。验证时不仅点击可见按钮，还要覆盖行事件、快捷操作和直接请求。

这说明权限 …

历史架构说明： 本文记录的是 fichil.com 早期运行在 VPS 与 Nginx 上时的排障过程。当前生产站已经迁移到 ChatGPT Sites，不再使用这里描述的服务器发布和回滚路径。现行架构见用 AI 开发与运维 fichil.com。

当时的故障表现是浏览器直接返回连接拒绝。这个错误发生在 HTTP 应用内容之前，因此排查重点不应先放在 Hugo 模板或文章文件，而应从网络与监听边界开始。

连接拒绝首先说明什么

连接拒绝通常表示域名已经解析出目标地址，网络请求也到达了对应主机，但目标端口没有进程接受连接，或被主机侧规则明确拒绝。

它与 DNS 解析失败、连接超时和 Nginx …

fichil.com 不只是一个放文章的页面，它也是我公开展示工作方法的工程项目：内容、应用代码、发布规则和线上版本都能追溯到同一个 Git 提交。

这里的“AI 开发与运维”并不表示把生产权限交给模型。AI 负责阅读上下文、提出修改、实现和执行验证；人负责确认需求、评审差异、合并代码和决定是否发布。

当前架构：内容源与生产应用分开

站点保留两层明确边界：

content/en + content/zh-cn
        ↓
Hugo Markdown（唯一文章源）
        ↓
内容生成与双语一致性检查
        ↓
vinext / React Sites 应用 …