api项目服务容器需按请求生命周期和资源复用特性设计：构造函数注入优于service()调用，单例仅适用于无状态资源类，标量参数须用闭包绑定，测试应直传mock依赖而非依赖容器。
API项目里服务容器不是“配好就能用”，而是得按请求生命周期和资源复用特性来设计。直接 service('SomeService') 拿实例没问题，但高频接口下容易踩内存、状态、并发三重坑。
构造函数注入比 service() 调用更可靠
控制器里手动调用 service('UserService') 看似简单，但每次请求都触发一次服务解析，尤其当 UserService 本身依赖数据库连接或缓存客户端时，会重复走反射+实例化路径。构造函数注入则由容器统一管理依赖树，在初始化阶段一次性完成。
- 必须显式声明类型提示，比如
public function __construct(UserService $userService) - 确保
UserService已在app/Config/Services.php中注册（哪怕只是return new UserService();） - 避免在构造函数里做耗时操作（如读配置文件、连外部 API），否则阻塞整个请求链路
标量参数（如 API 密钥、超时值）必须用闭包绑定
容器无法自动推断 string 或 int 类型参数该填什么值，硬写死在类里又不利于环境隔离。常见错误是把密钥直接塞进构造函数，导致测试环境无法切换。
- 在
app/Config/Services.php中用闭包绑定：$container->set('ApiClient', function ($container) { return new ApiClient($_ENV['API_KEY'] ?? 'dev-key', (int) ($_ENV['TIMEOUT'] ?? 5)); }); - 不要在闭包里调用
service()，否则可能引发循环依赖（比如ApiClient又需要Logger，而Logger又依赖ApiClient） - 环境变量优先级高于硬编码，默认值只用于本地开发，上线必须由 .env 控制
单例模式对 API 项目既是优化也是陷阱
数据库连接、Redis 客户端这类资源类适合单例，但业务服务如 OrderProcessor 如果带私有属性（比如临时订单 ID、用户上下文），复用实例会导致数据污染。
- 确认类无状态或状态完全来自方法参数，才可设为单例；CI4 默认不是单例，需显式调用
$container->singleton('OrderProcessor', ...) - 用
service('OrderProcessor')获取的永远是同一个实例，但new OrderProcessor()是新对象——两者混用极易出 bug - 日志、缓存、HTTP 客户端建议单例；含用户会话、请求上下文的类建议每次新建
测试时绕过容器直接传参更可控
单元测试里如果还走容器，就得 mock 整个依赖树，一环断全链崩。API 项目尤其要验证错误响应、限流逻辑等边界场景，这时构造函数直传依赖最干净。
- 测试控制器时，直接 new 实例并传入 mock 服务：
$controller = new UserController($mockUserService); - 确保构造函数参数都有默认值或允许 null（
UserService $userService = null），否则测试时无法跳过注入 - 不要在测试里调用
Services::injectMock()，它修改全局容器状态，多个测试间可能互相干扰
真正麻烦的不是怎么注册服务，而是判断哪些该共享、哪些该隔离、哪些该随请求销毁——这些决策点藏在业务逻辑深处，而不是配置文件里。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
