围绕真实项目里常见的 Liquibase（XML）反模式，按问题整理我目前更倾向采用的一些做法：schema 归属、master changelog 组织、changeSet ID 命名、XSD 版本、初始化策略、expand-and-contract、大表 DDL、K8s lock、回滚 / tag、context / labels、Testcontainers 验证与 CI 检查。

以问答方式整理我在微服务规模增大后开始补上的两类结构化文档：ADR 记录"为什么这样"，catalog-info.yaml 记录"是什么、归谁、依赖什么"。

以问答方式拆解我在 Shop Platform 中对 API 与 event contract 的兼容性保障：BFF 对外用 oasdiff 守 OpenAPI spec；内部 BFF→MS 和 MS→MS 用 JSON Schema 快照补 japicmp 的盲区；Kafka 事件用相同手法加 per-event schemaVersion。

BFF 调用多个下游 microservice 时，连接池要不要按服务隔离？connectTimeout / readTimeout 怎么 per-service 配置？Spring Boot 3.5 内部服务用 h2c 要避哪些坑？把这三个常见问题理清楚。

Spring Boot 3.5 + Java 25 微服务下，记录我如何用一个共享 starter 统一出站 HTTP 客户端的身份传播、错误语义、可观测性和弹性。

只共享 contracts 往往还不够——按我目前的理解，更稳妥的做法是把 ArchUnit、japicmp、Deprecation/Sunset 头、ignore-unknown、WireMock 这些检查组合起来。本文记录 Shop Platform 里的落地方式和一些可参考资料。

BFF 与微服务之间到底该共享到哪一步？本文从 Shop Platform 的 monorepo 实践出发，拆解共享 contracts、共享 client、契约测试三种思路在 polyrepo 下的 tradeoff，并记录我目前更倾向的落地方式。

在 code agent 普及的背景下，我在 Shop Platform 用 ArchUnit 作为可执行的 harness。本文结合实际实践，说明它在微服务、monorepo 与普通 repo 中的落地方式。

在多模块 Maven 单仓微服务平台中，我们选择了 Maven Archetype 而非 Spring Initializr 来管理服务脚手架。本文说明选型背后的原因、六类 Archetype 的分层逻辑、为什么我倾向给 Archetype 本身也加测试，以及版本维护策略。

Tracing 断链很少是 @HttpExchange 能解决的问题。一次 Spring Boot 3.5 + Micrometer + OpenTelemetry 的复盘：用 W3C Trace Context、baggage 白名单和 auto-configured RestClient.Builder 把 trace 和业务上下文一起稳定地跨服务传下去。