企业官网建设流程全解析

用 Docker 部署一套 Apollo 配置中心，再把它接入若依框架管配置，是我近两年在几个中小型项目里反复做的一件事。第一次做的时候踩了不少坑：镜像启动起来后 Portal 打不开、客户端拿不到配置、改了配置要重启才生效，前后折腾了两天才跑通。后来做多了，整理出一套相对稳定的步骤，从数据库初始化到若依工程改造，再到灰度发布和故障排查，基本能在一个下午搞定。

Apollo 是配置中心，解决的是“配置散落在各个 application.yml 里、改一个参数要重新打包发版”的问题；若依是一套很常见的后台管理脚手架，业务代码之外，配置项其实不少——文件上传路径、验证码开关、令牌有效期、第三方接口地址、限流阈值等。这两者结合，能覆盖大多数中小团队对“配置集中管理 + 动态生效”的需求。下面按我的实际落地顺序展开，适合已经能跑通若依、对 Docker 有基本概念的读者，零 Apollo 经验也能跟着走。

1. 动手之前先想清楚：若依为什么需要 Apollo

1.1 若依自带配置体系达到优化上限的三个场景

若依的配置放在application.yml和application-xxx.yml里，简单直接，单体部署时挺好用。但随着项目推进，它会遇到三个比较明显的问题。

第一是改配置必须重新打包。若依打成 jar 之后，application.yml被压在包内，想改一个上传路径都得重新构建、重新分发。虽然可以在启动时用--spring.config.location外挂配置文件，但外挂文件散落在每台机器上，时间一长就没人说得清哪台机器上是什么值。

第二是多实例配置不一致。若依做集群部署时，配置文件跟着镜像走，理论上一模一样，但只要有人手工改过某台机器的外挂配置，就会出现“同样请求打到不同节点行为不同”的排查困难。这类问题往往在出故障时才会暴露。

第三是配置变更没有留痕。谁在什么时候把验证码开关关了、把令牌有效期从 30 分钟改成 7 天，git log里也许有，但和线上实际运行的版本对不上。Apollo 的发布历史能完整记录每次改动，这是它很实用的特性之一。

1.2 Apollo 补上的关键能力

Apollo 提供的是“配置集中存储 + 客户端长轮询拉取 + 变更实时推送”这一整套能力。落到若依上，最直接的价值有三点。

其一是配置与代码分离。业务的开关类、阈值类配置全部挪到 Apollo，改完点发布，客户端秒级生效，不用重新打包。用@Value注入的字段会被 Apollo 自动更新，不用重启。

其二是环境与集群隔离。Apollo 用“环境（env）+ 集群（cluster）+ 命名空间（namespace）”三层模型组织配置。若依里的 dev、test、prod 可以直接对应 Apollo 的不同集群，同一份代码在不同环境跑，配置各管各的。

其三是发布审计与灰度。每次发布都有记录，能回滚；重要配置可以先对一两台机器灰度，观察没问题再全量。这一点在改数据库连接池参数、限流阈值这类“改错了会出事”的配置时特别有价值。

需要说明的是，Apollo 不是万能的。它解决的是“应用运行期可变的配置”，不解决“构建期参数”和“密钥托管”。数据库密码这类敏感信息放进 Apollo 是可以的，但要做好 Portal 的权限控制。

1.3 部署形态与版本怎么选

Apollo 官方提供了两种 Docker 形态，选错了后面会返工。

我踩过的坑是：一开始图省事用了 quick-start，验证完直接拿去做测试环境，结果容器一重启配置全没了——它内置的 MySQL 数据在容器层，删容器就丢。所以正式一点的环境，直接上分离部署，别犹豫。

版本上，Apollo 2.x 系列对 JDK 8 和 Spring Boot 2.x 的支持已经很稳定，若依主流的 3.8.x 版本用的是 Spring Boot 2.5.x，配 Apollo 2.2.0 比较稳妥。如果项目已经升到 Spring Boot 3.x，需要选支持 JDK 17 的更高版本，具体以发布说明为准，别凭印象选。

2. Docker 部署 Apollo 的完整过程

2.1 环境核算与目录规划

先算资源。分离部署的最小组合是三个 Java 服务加一个 MySQL，我一般按下面这个规格起步：

这四个加起来，一台 4 核 8G 的机器跑起来比较舒服，2 核 4G 也能跑，但 MySQL 和三个 JVM 抢内存会比较难受，尤其是 Portal 启动时。

目录规划上我习惯这样组织，方便备份和迁移：

/opt/apollo/ ├── docker-compose.yml ├── sql/ # 两个初始化脚本 ├── logs/ │ ├── config/ │ ├── admin/ │ └── portal/ └── data/ └── mysql/

日志目录一定要挂出来。Apollo 排障高度依赖客户端日志和服务端日志，容器一删日志全没，后悔都来不及。

注意：如果机器上已经跑着 8080 端口的服务（很常见，很多网关和后台都占这个端口），务必提前换掉，或者把 Config Service 的映射端口改成 18080。端口冲突导致的启动失败排查起来很浪费时间。

2.2 数据库初始化：两个库别搞混

Apollo 用两个独立的数据库：ApolloConfigDB存配置本身，ApolloPortalDB存 Portal 的用户、项目、权限信息。两个都要建，缺一个 Portal 就起不来。

初始化脚本官方在源码仓库的scripts/sql/目录下，拿到apolloconfigdb.sql和apolloportaldb.sql两个文件后执行：

mysql -h 127.0.0.1 -uroot -p < apolloconfigdb.sql mysql -h 127.0.0.1 -uroot -p < apolloportaldb.sql

执行完先别急着起容器，有两处配置必须先改，否则客户端永远连不上。

第一处是ApolloConfigDB的ServerConfig表，要把eureka.service.url改成 Config Service 对外可达的地址：

UPDATE `ServerConfig` SET `Value` = 'http://10.0.0.11:8080/eureka/' WHERE `Key` = 'eureka.service.url';

这一条是整个链路的关键。Admin Service 启动时会去读这个地址，把自己注册到 Eureka；客户端也从这里知道有哪些 Config Service 实例可用。填错了的表现是：服务能起来，但客户端一直报连不上 meta。

第二处是ApolloPortalDB的ServerConfig表，告诉 Portal 每个环境对应的 meta 地址：

UPDATE `ServerConfig` SET `Value` = '{"DEV":"http://10.0.0.11:8080"}' WHERE `Key` = 'apollo.portal.meta.servers'; UPDATE `ServerConfig` SET `Value` = 'DEV' WHERE `Key` = 'apollo.portal.envs';

apollo.portal.meta.servers是个 JSON，key 必须是大写的环境名；apollo.portal.envs决定 Portal 顶部能切换几个环境。只做一套环境就写DEV，想加测试环境就得再加一套 Config DB，这个成本要提前评估。

注意：MySQL 8.0 建库时字符集务必用utf8mb4，连接串里带上characterEncoding=utf8&serverTimezone=Asia/Shanghai。少了时区参数，发布记录的时间会差 8 小时，排查问题时会误判先后顺序。

2.3 编排文件编写与关键环境变量

三个服务的镜像官方都有，直接用。编排文件我一般写成这样：

version: "3.8" services: apollo-config-service: image: apolloconfig/apollo-config-service:2.2.0 container_name: apollo-config-service restart: always ports: - "8080:8080" environment: SPRING_DATASOURCE_URL: jdbc:mysql://10.0.0.11:3306/ApolloConfigDB?characterEncoding=utf8&serverTimezone=Asia/Shanghai SPRING_DATASOURCE_USERNAME: apollo SPRING_DATASOURCE_PASSWORD: 你的密码 EUREKA_INSTANCE_IP_ADDRESS: 10.0.0.11 TZ: Asia/Shanghai JAVA_OPTS: "-Xms512m -Xmx1024m" volumes: - ./logs/config:/opt/logs apollo-admin-service: image: apolloconfig/apollo-admin-service:2.2.0 container_name: apollo-admin-service restart: always depends_on: - apollo-config-service ports: - "8090:8090" environment: SPRING_DATASOURCE_URL: jdbc:mysql://10.0.0.11:3306/ApolloConfigDB?characterEncoding=utf8&serverTimezone=Asia/Shanghai SPRING_DATASOURCE_USERNAME: apollo SPRING_DATASOURCE_PASSWORD: 你的密码 EUREKA_INSTANCE_IP_ADDRESS: 10.0.0.11 TZ: Asia/Shanghai JAVA_OPTS: "-Xms512m -Xmx1024m" volumes: - ./logs/admin:/opt/logs apollo-portal: image: apolloconfig/apollo-portal:2.2.0 container_name: apollo-portal restart: always depends_on: - apollo-admin-service ports: - "8070:8070" environment: SPRING_DATASOURCE_URL: jdbc:mysql://10.0.0.11:3306/ApolloPortalDB?characterEncoding=utf8&serverTimezone=Asia/Shanghai SPRING_DATASOURCE_USERNAME: apollo SPRING_DATASOURCE_PASSWORD: 你的密码 TZ: Asia/Shanghai JAVA_OPTS: "-Xms512m -Xmx1024m" volumes: - ./logs/portal:/opt/logs

几个环境变量值得单独说明。EUREKA_INSTANCE_IP_ADDRESS告诉 Config Service 和 Admin Service 用哪个 IP 注册到 Eureka，在多网卡的机器上不指定会注册成容器内部 IP，外部客户端就找不到。TZ是为了让日志和发布记录的时间对得上，少了它排查问题时时间线会错乱。

JAVA_OPTS里的内存值别照抄，按机器实际内存调整。我见过在 4G 机器上三个服务各给 2G 堆内存直接 OOM 的情况，容器被系统杀掉之后还以为是镜像问题。

2.4 启动顺序、健康检查与首轮验证

顺序很重要：Config Service 要先起来，因为 Admin Service 启动时要注册到它内置的 Eureka。depends_on只保证容器启动顺序，不保证服务就绪，所以启动后要等一会儿。

验证分三步，一步都不能跳。

第一步，看 Config Service 的 Eureka 是否正常：

curl -s http://10.0.0.11:8080/eureka/apps

返回的 XML 里应该能看到APOLLO-ADMINSERVICE这个应用，实例状态是UP。如果只有APOLLO-CONFIGSERVICE没有 Admin，说明 Admin 没注册上，回头检查eureka.service.url。

第二步，看 Admin Service 是否健康：

curl -s http://10.0.0.11:8090/health

返回{"status":"UP"}就对了。

第三步，浏览器打开http://10.0.0.11:8070，默认账号apollo、密码admin。登录进去能创建项目、能切到 DEV 环境，说明链路通了。

提示：首次登录后第一件事就是把默认密码改掉，然后把apollo账号的角色降级或者禁用，用独立的账号做日常操作。默认口令留着不管，配置中心的权限等于形同虚设。

2.5 环境与命名空间的初始规划

建项目之前，先把组织结构定下来，后面改起来麻烦。

环境上，如果只有一套 Config DB，那就只有 DEV。想加测试环境和生产环境，要么再起两套 Config DB，要么用集群（cluster）来区分。我的经验是：中小项目用集群更划算，一套 DB，建default、test、prod三个集群，客户端通过apollo.cluster指定连哪个。代价是每次发布要针对三个集群分别点发布，稍嫌繁琐，但省了一套数据库和一组服务。

命名空间上，application是每个项目自带的私有命名空间，键值对格式。如果配置量大、想按模块拆，可以再建几个私有命名空间，比如ruoyi-business、ruoyi-thirdparty。格式上，properties 类型的命名空间直接写名字，YAML 类型的要带后缀，比如ruoyi.yaml。

这里有个容易忽略的点：命名空间一旦创建，类型不能改，只能删了重建。所以建之前想清楚用 properties 还是 YAML。properties 的好处是键值扁平、在 Portal 里单条编辑，改一个值不会影响别的；YAML 的好处是层级清晰，但整块编辑时容易手抖缩进错。我一般业务配置用 properties，结构化的复杂配置才用 YAML。

3. 若依工程侧的接入改造

3.1 依赖引入与版本对齐

若依的ruoyi-admin模块是启动入口，依赖加在它的pom.xml里，或者加到父工程的dependencyManagement统一管理：

<dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactId>apollo-client</artifactId> <version>2.2.0</version> </dependency>

版本对齐是要点。Apollo 客户端会和 Spring 的Environment、PropertySource打交道，版本不匹配时症状很隐蔽——应用能启动，某些配置也生效，但动态刷新时灵时不灵。若依 3.8.x 用 Spring Boot 2.5.x，配 Apollo 2.2.0 是经过验证的组合；如果用的是更早的若依版本（Spring Boot 2.2 及以下），可以考虑 Apollo 1.9.x。

引入之后先跑一遍mvn dependency:tree，看看有没有 Groovy、Guava 之类的传递依赖和若依里已有的版本打架。Apollo 客户端依赖了一部分 Guava，若依本身也可能引用，冲突时按实际报错排除，别盲目<exclusions>。

3.2 配置文件调整范围与保留项取舍

这是最需要判断力的部分。我的原则是：基础运行参数留在本地，业务可变参数进 Apollo。

具体来说，数据源、Redis 连接、MyBatis、日志文件路径这些留在application.yml里。原因很现实：这些配置在应用启动早期就要用到，如果 Apollo 服务挂了或者网络抖动，应用连启动都启动不了，可用性反而下降。而 Apollo 的客户端在拉不到配置时会用本地缓存，但首次启动没有缓存，风险就落在这一下。

业务参数则全部搬走，比如：

• 验证码开关、令牌有效期
• 文件上传的大小限制、允许后缀
• 接口限流阈值、并发开关
• 第三方接口地址、超时时间
• 各类业务开关（是否开启审核、是否开启短信验证等）

application.yml里加这么几行：

app: id: ruoyi-admin apollo: meta: http://10.0.0.11:8080 cluster: default cacheDir: /opt/data bootstrap: enabled: true namespaces: application,ruoyi-business eagerLoad: enabled: true autoUpdateInjectedSpringProperties: true

app.id必须和 Portal 里创建项目时填的 AppId 完全一致，大小写敏感，多一个横线少一个横线都拉不到配置。eagerLoad.enabled设为 true 是为了在日志系统初始化之前就把配置加载好，否则日志级别之类的配置会失效。cacheDir建议显式指定并挂载出来，容器重启后命中缓存，启动更快，也不会因为 Apollo 暂时不可用而卡住。

注意：Apollo 读取配置项用的是原始 key，别自作聪明改写成 kebab-case。apollo.cacheDir写成apollo.cache-dir在部分版本里读不到，会静默使用默认值，排查时很难想到是这原因。

3.3 启动类注解与配置加载顺序

启动类上加一个注解：

@EnableApolloConfig({"application", "ruoyi-business"}) @SpringBootApplication public class RuoYiApplication { public static void main(String[] args) { SpringApplication.run(RuoYiApplication.class, args); } }

实际加载动作是由 Apollo 的ApplicationContextInitializer完成的，这个类在spring.factories里注册，启动时自动生效。注解的作用更偏向显式声明和给@ApolloConfig注入指明命名空间，加上它主要是让后来人一眼看明白配置从哪来。

加载顺序上有个细节值得说清楚。Apollo 加载完成后，会把配置作为一个PropertySource插到Environment的最前面（默认行为），也就是说 Apollo 上的同名 key 会覆盖本地application.yml。这个设计本身合理，但有个副作用：如果有人在 Apollo 上误配了spring.datasource.url，应用启动就会连到错误的库，而且本地配置改回去也没用。

如果确实需要本地配置优先，可以调整顺序：

apollo: property: source: order: -1

或者干脆遵守约定：Apollo 上不配基础连接类参数，从根上避免冲突。

3.4 业务配置的迁移与动态刷新

搬配置不是复制粘贴就完事，要区分“能热更新”和“不能热更新”两类。

用@Value注入的简单类型，Apollo 会通过ApolloAnnotationProcessor自动更新字段值，因为 Apollo 会在运行时修改 Bean 的字段。这个能力默认开启，用起来无感：

@Component public class UploadSetting { @Value("${ruoyi.upload.max-size:10}") private int maxSizeMb; public int getMaxSizeMb() { return maxSizeMb; } }

用@ConfigurationProperties绑定的对象也能更新，前提是autoUpdateInjectedSpringProperties为 true（默认就是）。但要注意，绑定的对象如果被别的 Bean 在初始化时读取过一次并缓存了结果，热更新后的新值不会自动反映过去。

典型例子是数据源和线程池。把连接池最大连接数放到 Apollo，改了之后HikariDataSource并不会重新调整，必须重启。这类配置老老实实重启，别指望热更新。

对于日志级别的动态调整，logging.level.xxx放在 Apollo 上不会自动生效，因为 Spring Boot 的日志系统在启动时就初始化完毕了。想要动态改，得自己写监听器：

@Component public class LogLevelChangeListener { private final LoggingSystem loggingSystem; public LogLevelChangeListener(LoggingSystem loggingSystem) { this.loggingSystem = loggingSystem; } @ApolloConfigChangeListener(value = "application", interestedKeyPrefixes = {"logging.level."}) public void onChange(ConfigChangeEvent event) { for (String key : event.changedKeys()) { ConfigChange change = event.getChange(key); String loggerName = key.substring("logging.level.".length()); if ("root".equals(loggerName)) { loggerName = LoggingSystem.ROOT_LOGGER_NAME; } loggingSystem.setLogLevel(loggerName, LogLevel.valueOf(change.getNewValue().toUpperCase())); } } }

这段代码我实测能用，线上排障时直接通过 Portal 把某个包的日志级别调到 DEBUG，观察完再调回去，全程不用重启。相比改配置文件再发布，效率提升非常明显。

3.5 打包与容器化运行

若依打成 jar 之后，启动参数里要把 Apollo 的关键信息带上，尤其是容器化部署时环境变量比配置文件灵活：

java -Dapp.id=ruoyi-admin \ -Dapollo.meta=http://10.0.0.11:8080 \ -Dapollo.cacheDir=/opt/data \ -jar ruoyi-admin.jar

-D参数必须写在-jar前面，写到后面会被当成应用程序参数传给main方法，不会进 JVM 系统属性。这个低级错误我见过不止一次。

如果用 Docker 跑若依，Dockerfile 里把缓存目录挂载出来，否则每次重建容器都要重新拉一遍全量配置：

FROM openjdk:8-jdk-alpine ENV TZ=Asia/Shanghai VOLUME /opt/data COPY ruoyi-admin.jar /app.jar ENTRYPOINT ["java", "-Dapollo.cacheDir=/opt/data", "-jar", "/app.jar"]

客户端日志默认落在~/logs/{appId}/apollo/下，容器里就是/root/logs/ruoyi-admin/apollo/。排障时先看这个目录里的apollo-client.log，里面会打印拉取到了哪个 namespace、连的是哪个 config service、有没有走本地缓存，信息比应用日志详细得多。

4. 发布、回滚与权限管理

4.1 灰度发布的使用方式

Apollo 的灰度发布支持按 IP 和按标签两种方式。按 IP 最直观：先把某个新配置灰度到一台机器，观察它的行为，没问题再全量。

操作流程是：在 Portal 的配置页面点“灰度发布”，选择目标 IP，填写新值，发布。这时候被选中的机器会拿到新值，其他机器还是旧值。观察一段时间没问题，点“全量发布”；有问题点“放弃灰度”，被灰度的机器会回退到主版本配置。

这个功能在改限流阈值、切第三方接口地址时特别有用。我一般的做法是灰度一台边缘节点，观察 10 分钟，看错误率和响应时间，再决定是否全量。相比直接全量发布然后回滚，灰度给了缓冲时间。

提示：灰度版本的全量发布是一次“覆盖”，会把灰度值写进主版本。发布前确认灰度值是对的，别把观察期的临时值当成最终值全量推出去。

4.2 配置回滚的实际操作

每次发布都会生成一条 Release 记录，Portal 的“发布历史”里能看到完整列表。回滚就是选中上一个版本，点回滚，客户端会收到变更通知并把值改回去。

回滚有个前提：客户端还在运行并且连着 Config Service。如果客户端已经下线，回滚只改服务端，客户端下次启动才会拿到旧值。

需要提醒的是，回滚只回滚配置，不回滚业务状态。如果某个配置导致写入了错误数据，回滚配置并不能把数据改回来。所以涉及数据写入的开关，灰度 + 观察是必须的步骤，不能省。

4.3 权限模型与最小授权

Apollo 的权限分三层：Portal 管理员、项目管理员、项目成员。项目成员里又可以细分编辑权限和发布权限。

我的建议是：编辑权和发布权分开。日常开发人员给编辑权限，可以改草稿、提交变更，但点不了“发布”按钮；发布权限只给一两个人。这样能杜绝“调试时随手一改直接发布到生产”的事故。这个配置在项目的“管理员工具 - 权限管理”里调整，不复杂，但很值得做。

另外，Apollo 支持给敏感配置加密。如果数据库密码这类信息必须放 Apollo，可以用官方的加密方式，配置一个密钥，界面上显示为密文。密钥本身通过启动参数传入，不落配置文件。

4.4 客户端缓存与降级行为

Apollo 客户端在本地有一个缓存目录，每次拉取成功都会写一份快照。当 Config Service 不可达时，客户端会退回到本地缓存，应用能正常启动，只是拿不到最新配置。

这个机制是可用性的保障，但也带来一个问题：如果 Apollo 上改了配置，某台机器的网络恰好不通，它就会一直用着旧值，而且从应用层面看一切正常。所以监控上要把“配置版本落后”作为一个指标，定期比对客户端上报的配置版本和服务端最新版本。

配置缓存的默认位置在 Linux 是/opt/data/，Windows 是C:\opt\data\。容器里跑记得挂载，不然容器重建就丢。缓存文件是明文 JSON，敏感信息放 Apollo 时要注意宿主机的文件权限。

5. 踩坑实录与排查速查表

5.1 启动阶段的高频报错

报错一：ApolloConfigException: Unable to load config from ...

这个报错基本可以锁定为连不上 Config Service。排查顺序是：先在应用所在机器上curl http://10.0.0.11:8080/services/config，看能不能返回服务列表；不通就是网络或端口问题；通了还报错，就检查app.id和 Portal 里的项目 AppId 是否一致。

报错二：Admin Service 起不来，日志里全是 Eureka 注册失败

八成是eureka.service.url配错了，或者 Config Service 还没完全启动。前者去ApolloConfigDB.ServerConfig表里核对，后者等 Config Service 的/health返回 UP 之后再重启 Admin Service。

报错三：Portal 登录后一片空白，或者报 500

先看 Portal 日志里有没有数据库连接异常。ApolloPortalDB的连接串写错、字符集不对、MySQL 用户没有远程访问权限，都会导致这个现象。还有一种可能是apollo.portal.meta.servers的 JSON 格式不合法，Portal 解析失败但日志里报得比较隐晦。

5.2 运行阶段的疑难杂症

现象：Portal 上改了配置，应用日志显示收到了变更通知，但业务逻辑用的还是旧值

这是最典型的问题，原因通常有三类。一是配置注入的位置不对，比如在static字段上用了@Value，Apollo 改不了静态字段；二是值被缓存了，比如在@PostConstruct里把值读出来存进了一个final变量；三是@ConfigurationProperties的对象没有被 Spring 管理，手动new出来的对象不会更新。

排查方法是在变更监听器里打印一下当前字段值，确认反射有没有生效。Apollo 的ApolloAnnotationProcessor是通过反射改字段的，字段如果是private final或者被内联优化了，都会失败。

现象：应用启动特别慢，日志里一直在等 Apollo

apollo.bootstrap.eagerLoad.enabled为 true 时，应用会同步等 Apollo 返回结果，超时时间默认比较长。如果 Config Service 网络慢，启动就会卡住。可以调小超时时间：

apollo: accesskey: secret: 你的密钥 connectTimeout: 2000 readTimeout: 3000

另外保证装了本地缓存之后，第二次启动会快很多，因为会先读缓存再异步刷新。

现象：某个命名空间里的配置全都不生效

先确认这个命名空间是不是已经发布了。Apollo 的配置有“编辑”和“发布”两个状态，编辑完不点发布，客户端拉到的还是上一版。这个坑新手特别容易踩，尤其是在有多个命名空间的时候，只发布了一个，另一个忘了。

再确认命名空间的格式。YAML 类型必须写全后缀，ruoyi.yaml，写成ruoyi拉不到。properties 类型不带后缀。混了就不生效。

5.3 常见问题速查表

这些坑里，我认为最值得提前预防的是“未发布”和“本地缓存”两个。前者靠流程约束——每次改完配置自觉点发布；后者靠部署规范——缓存目录固定挂载，出问题时清缓存重启是最快的手段。

最后分享一个我一直在用的小习惯：在若依的启动类里加一段启动日志，把当前生效的 Apollo 配置版本号和 cluster 打印出来。排查“为什么这台机器行为和别的不一样”时，第一眼看这段日志，能省掉大量猜测。配置治理这件事，工具只是提供能力，真正决定稳定性的还是这些看起来不起眼的约定。