apollo分布式部署核心卡点是数据库初始化顺序、eureka.service.url配置时机及$java_home是否生效；mysql 8.0+需先改认证插件再导入sql，两库须分离且密码禁空格，application-github.properties中url与环境须严格匹配，服务必须按configservice→adminservice→portal顺序启动并正确注册ip。
直接上结论：Apollo 分布式部署不是“装完三个包就完事”，核心卡点在数据库初始化顺序、eureka.service.url 配置时机、以及 $JAVA_HOME 是否真正生效——90% 的启动失败都发生在这三处。
MySQL 8.0+ 连不上？先改认证插件再导入 SQL
MySQL 8.0 默认用 caching_sha2_password，但 Apollo 启动时会报 Client does not support authentication protocol。这不是密码错，是驱动不认新插件。
- 用 root 登录 MySQL 后立即执行：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_password'; - 必须先执行这条，再导入
apolloportaldb.sql和apolloconfigdb.sql；跳过 portal 库会导致 Portal 根本打不开 - 两个库要分开建：
ApolloPortalDB（只一套，供 Portal 用）、ApolloConfigDB（每个环境一套，DEV/FAT/UAT/PRO 各自独立） - 密码里不能有空格，否则
spring.datasource.password解析失败，日志里只显示“Connection refused”，实际是连接池没起来
application-github.properties 里哪些配置不能错
这个文件在 apollo-configservice/conf/ 和 apollo-adminservice/conf/ 下各一份，内容高度相似但用途不同。最容易被忽略的是：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
spring.datasource.url必须指向对应环境的ApolloConfigDB（比如 DEV 环境就写jdbc:mysql://10.1.1.1:3306/ApolloConfigDB_DEV），不能全写 localhost —— 分布式部署时 ConfigService 和 DB 往往不在同一台机器 -
eureka.service.url不是启动后才配，而是在启动前就得设好。如果只部署单节点，可写http://localhost:8080/eureka/；多节点必须提前在ApolloConfigDB.ServerConfig表里更新：UPDATE ServerConfig SET Value='http://10.1.1.1:8080/eureka/,http://10.1.1.2:8080/eureka/' WHERE `Key`='eureka.service.url'; -
apollo.profile要显式设为github，否则读不到application-github.properties，而是 fallback 到空配置
服务启动顺序和网络注册问题
ConfigService 启动失败，大概率不是它自己崩了，而是它注册不到 Eureka 或者注册了错误 IP。常见现象是 curl http://127.0.0.1:8080/eureka/apps 返回空或 404。
- 必须按
configservice → adminservice → portal顺序启动，Portal 依赖 AdminService 提供 API，AdminService 又依赖 ConfigService 的元数据服务 - 如果机器有 docker0 或 veth* 网卡，ConfigService 会默认把 docker 网段 IP 注册进 Eureka，导致客户端连不上。解决方法是在
startup.sh的 JVM 参数里加：-Dspring.cloud.inetutils.ignoredInterfaces[0]=docker0 -Dspring.cloud.inetutils.ignoredInterfaces[1]=veth.* - Portal 访问不了？检查
apollo-portal/conf/apollo-env.properties，里面每个环境的 meta 地址必须指向 ConfigService 的真实域名或 IP，例如：dev.meta=http://10.1.1.1:8080，不能写localhost
验证是否真跑通的三个关键 curl
别光看进程在不在，得看服务之间能不能互相说话：
- ConfigService 自检：
curl -s http://10.1.1.1:8080/eureka/apps | grep CONFIGSERVICE—— 应该返回一个实例 - AdminService 是否注册成功：
curl -s http://10.1.1.1:8080/eureka/apps | grep ADMINSERVICE—— 如果没有，说明它没连上 ConfigService 的 Eureka - Portal 能否拉到配置：
curl "http://10.1.1.1:8070/configs/demo/DEV/application?ip=127.0.0.1"—— 替换demo为你的 appId，返回 JSON 才算通
最易被绕开的细节：Portal 的 apollo-env.properties 是静态配置，改完必须重启 Portal；而 ConfigService 的 eureka.service.url 是运行时从 DB 加载的，改完 DB 后只需发个 POST /notify 触发刷新，不用重启。
