3 月 22 日，我把求职平台后端的名字从 OfferNow 改成了 OfferWave。决定只用了几分钟，执行却花了一整个晚上。改名这件事最容易低估的地方在于：名字不只出现在标题里，它会渗进每一层配置。
名字藏在哪些地方
我先把改动按层列了出来，结果比预想的长：
- Maven 坐标：
groupId从com.offernow改成com.offerwave，artifactId从offernow-backend改成offerwave-backend，Spring 应用名跟着改。 - 代码：主源码和测试源码的包名整体迁移，启动类从
OfferNowApplication变成OfferWaveApplication，MyBatis 的实体包配置也要同步。 - 配置：业务配置前缀从
offernow.*换成offerwave.*，JWT、爬虫、邮件、存储四组配置都受影响。 - 环境变量：存储相关的
OFFERNOW_*全部换成OFFERWAVE_*。 - 数据：默认数据库名从
offer_now改成offerwave，建库脚本和会话脚本改文件名。 - 周边：本地启动配置、接口文档标题、OpenAPI 标题、README，甚至邮件主题里的项目名。
这张清单让我意识到，项目名其实是一种隐性的接口。代码里改完能编译，只能说明 Java 这一层没问题；配置前缀、环境变量和数据库名，都是部署环境和代码之间的约定，改了一边忘了另一边，应用照样能启动，只是会悄悄读不到配置。
兼容性要写给以后的自己
所以我在版本说明里专门留了一节兼容性：外部部署还在用 offernow.* 前缀的要改，环境变量还是 OFFERNOW_* 的要改，数据库实际还叫 offer_now 的，要么改名，要么用 DB_URL 显式覆盖；IDE、脚本或部署平台里引用旧启动类的，也要一起换。
这些话现在看起来啰嗦，但一个月之后再部署，我大概已经不记得哪些地方曾经叫 OfferNow 了。
用扫描收尾
最后一步是全局扫描：在整个仓库里搜 OfferNow、offernow 和 offer_now 三种写法，确认没有残留引用。三种写法是故意分开的——驼峰、全小写和下划线，分别对应类名、配置和数据库，任何一种漏掉都会留下一个将来才会炸的坑。
扫描结果为空的时候，我才觉得这次改名真的结束了。
上一次改动的影子
改名之前一个月，2 月底的 v1.1.0 刚刚改过一次约定：内部爬虫同步接口从 X-API-KEY 改成只接受管理员 JWT，调用方的认证头必须跟着改。那次我也写了兼容性说明。
两次改动放在一起看，规律很明显：凡是跨越代码边界的东西——认证头、配置前缀、环境变量、数据库名——改动时都要当成接口变更来对待，写清楚旧的是什么、新的是什么、谁需要跟着动。