thinkphp本身不提供微服务通信能力，硬用curl_init()或file_get_contents()调其他服务等于放弃重试、超时控制、连接复用和上下文透传；必须使用显式超时设置、句柄复用、json编码校验、环境变量管理服务地址，并通过独立composer包或接口抽象实现应用间解耦。
ThinkPHP 本身不提供微服务通信能力，硬用 curl_init() 或 file_get_contents() 调其他服务，等于放弃重试、超时控制、连接复用和上下文透传——这不是微服务通信，是裸 HTTP 轮询。
别在控制器里手写 curl 调远程服务
常见错误现象：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，各应用自己实现，调用方只依赖接口
用 Swoole + JSON-RPC 自建轻量闭环
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 不一致，线上出问题难排查 - 若两个应用都用 TP，优先走
Swoole\Coroutine\Http\Client（需开启协程），比原生 cURL 延迟低且连接可复用
最易被忽略的一点：服务地址绝不能硬编码。用 getenv('ORDER_SERVICE_URL') 读环境变量，Docker/K8s 注入，PHP-FPM 里配 php_admin_value[env[ORDER_SERVICE_URL]]；需要按路径分流（如 /v2/ 走新服务），自己写个轻量路由函数就行，别引入 Guzzle 这类重型客户端。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
