thinkphp本身不提供微服务能力，硬用curl调用等于裸http轮询；必须显式设连接与超时时间、复用句柄、校验json编码、禁用dns缓存；多应用共享逻辑须抽为独立composer包或接口抽象，禁用require跨应用代码。
ThinkPHP 本身不是微服务框架，硬套“微服务开发教程”容易走偏——它不提供服务注册、发现、熔断、链路追踪等能力，强行在 TP 里写 curl_init() 调其他 TP 应用，只会得到一堆不可观测、难调试、无重试的 HTTP 轮询。
为什么别在控制器里手写 curl 调其他 TP 服务
常见错误现象：CURLOPT_TIMEOUT 设了但漏掉 CURLOPT_CONNECTTIMEOUT_MS，DNS 解析卡住十几秒才失败；每次请求都新建 cURL 句柄，压测时触发 Too many open files；json_encode($data) 返回 false 却直接塞进 CURLOPT_POSTFIELDS，后端收到字符串 "false" 导致解析失败。
必须做到：
- 显式设
CURLOPT_CONNECTTIMEOUT_MS（推荐 1000）和CURLOPT_TIMEOUT_MS（推荐 3000） - 复用同一个
curl_init()返回的句柄，用curl_setopt_array()动态改CURLOPT_URL和CURLOPT_POSTFIELDS - 调用前判断
$json = json_encode($data)是否为false，出错时用json_last_error_msg()查原因（比如含资源或循环引用） - 手动加
Content-Length: ' . strlen($json)到CURLOPT_HTTPHEADER，避免代理截断 - 禁用 DNS 缓存：设
CURLOPT_DNS_CACHE_TIMEOUT为-1，复用系统缓存
两个 TP 应用共享逻辑，为什么不能 require 公共目录
直接 require 另一个应用的 app/service/UserService.php，会触发命名空间加载冲突、容器未初始化、环境配置错乱。典型报错：Class 'app\service\UserService' not found 或 Call to a member function xxx() on null。
正确做法是：
- 抽成独立 Composer 包，
composer require vendor/common-service引入，而非alias或extend_path - 包内不能硬依赖
thinkphp/framework的具体版本，否则 TP6.2 和 TP6.3 容器接口微变就崩 - 临时解耦可用「接口 + 桩实现」：公共包只定义
UserInterface，各应用自己实现，调用方只依赖接口
想轻量闭环，不如手写 JsonRpcClient
ThinkPHP 自身无 RPC 客户端，think-service 扩展只是注册中心包装，不解决通信层问题。真要轻量，直接手写一个 JsonRpcClient 类，用 POST + application/json 就够用。
服务端用 Swoole\Http\Server 或 think-worker 启动，接收 POST 请求，解析 method + params，反射调用本地服务；客户端统一封装 call($method, $params)，自动加 X-Request-ID、序列化、重试逻辑。
注意：think run 默认禁用协程 Hook、不支持热 reload、中间件加载顺序和 FPM 模式不一致——线上出问题很难排查。真实场景下建议绕过它，手写启动脚本，手动调用 Swoole\Runtime::enableCoroutine(true)，否则 Db::query() 会阻塞整个进程。
真正需要微服务能力时，TP 更适合作为「消费者」或「边缘网关」，而不是服务网格里的节点。复杂点在于：服务间上下文透传（如 trace_id）、失败降级策略、异步事件解耦——这些都不是加几行 curl 就能搞定的，得从架构层面选型，而不是在框架缝里硬塞。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
