Composer本身不提供微服务治理能力，它仅负责依赖安装，真正的服务注册、健康检查、实例发现均由Consul等外部注册中心实现，Composer只是将交互SDK引入项目。
为什么直接用 Composer 库做微服务治理行不通
Composer 是 PHP 的依赖管理工具，不是服务发现或健康检查框架。它不提供运行时服务注册、心跳探测、实例列表拉取等能力。你看到的所谓“支持自动发现”的库（比如 php-service-discovery 或 microservice-registry），本质是封装了与 Consul / Etcd / Nacos 的 HTTP API 交互逻辑，Composer 只负责把这段逻辑装进来——真正干活的是后端注册中心，不是 Composer。
常见误解：把 composer require xxx/micro-service 当成开箱即用的治理方案。实际装完才发现要手动配地址、写心跳定时器、处理超时重试、自己实现负载均衡策略。
- 没有内置服务端，必须额外部署 Consul 等中间件
- 健康检查默认只调用
/health，但你的服务可能用/ping或带 token 验证 - 服务发现返回的 IP+端口常是容器内网地址，直接用于客户端请求会失败
如何让 PHP 微服务真正“自动发现”
核心不是选哪个 Composer 包，而是统一约定注册/发现协议，并在启动和退出时触发动作。推荐用 consul-php-sdk（非官方但维护活跃）配合脚本化生命周期管理。
关键实操点：
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 服务启动时，用
Consul::agentServiceRegister()注册，check字段必须包含http、interval和timeout，例如："http": "http://127.0.0.1:8080/health", "interval": "10s", "timeout": "5s" - 不要依赖 SDK 的自动重连——Consul 连接断开后，SDK 不会自动重新注册服务，需监听
ConnectionException并触发agentServiceDeregister()+ 重试注册 - 客户端发现时，别直接用
Consul::healthService()返回的Service.Address；优先取Service.TaggedAddresses["lan"]或通过环境变量覆盖（如DISCOVERY_HOST=prod-api.example.com）
健康检查端点怎么写才不被误判下线
Consul 默认用 HTTP 状态码 2xx 判定健康，但很多 PHP 框架在 DB 连接失败时仍返回 200 + 错误 JSON。这会导致服务“活着却被认为不健康”或“不健康却一直挂着”。
正确做法：
- 健康检查接口必须是独立路由（如
/health），不复用业务中间件（尤其不要走 Auth、RateLimit） - 检查项分层：基础层（PHP 进程存活、内存未耗尽）→ 依赖层（MySQL ping、Redis ping、下游 HTTP 服务可连通）→ 业务层（可选，如核心订单表能 SELECT）
- 响应体无需复杂结构，Consul 只看状态码；但建议返回简明 JSON 方便人工排查，例如：
{"status":"pass","checks":{"db":"ok","redis":"ok"}} - 超时时间必须小于 Consul 的
timeout设置，否则 Consul 先判定超时下线，你的脚本还没来得及返回结果
本地开发与生产环境的服务发现差异怎么抹平
本地跑 docker-compose up consul php-app 很方便，但上线后服务跨主机、跨 VPC，DNS 解析、网络策略、TLS 证书全都不一样。硬编码 Consul 地址或服务名必然出问题。
务实方案：
- 用环境变量驱动配置：启动时读
CONSUL_ADDR、SERVICE_NAME、HEALTH_CHECK_URL，而不是写死在config.php里 - 本地开发用
host.docker.internal指向宿主机，避免容器内无法访问宿主 Consul；生产用 Kubernetes Headless Service 或 CoreDNS 域名 - 服务名不要用
user-service-v1这种带版本的，改用user-service+ 标签（version=v1），靠标签做灰度，避免客户端改代码 - PHP-FPM 场景下，
register和deregister必须放在 FPM 的onStartup和onShutdown钩子中，不能放在 Web 请求里——否则一个请求结束就注销服务
最易忽略的点：PHP CLI 启动的 Worker 进程（如队列消费者）也要单独注册为服务，且健康检查需独立实现（比如检测 Redis 队列长度是否积压），不能复用 Web 接口的 /health。
