symfony功能测试模拟真实http请求，走完整生命周期，用kerneltestcase+createclient发起请求，验证响应状态码与内容，不测控制器内部逻辑，业务逻辑应抽离为可单元测试的服务。
Symfony 功能测试不是“测控制器本身”，而是模拟真实 HTTP 请求，走完整请求生命周期——从路由匹配、控制器执行、响应生成，到中间件、事件、安全防火墙等全部环节。它不关心控制器内部怎么写，只验证“给定请求，是否得到预期响应”。
用 KernelTestCase + createClient 发起真实请求
这是最标准、最推荐的方式。继承 KernelTestCase（不是普通 TestCase），它能启动轻量内核，加载容器、路由、配置等运行时环境。
- 在测试类中调用 static::createClient() 获取已启动内核的测试客户端，不要手动 new 控制器或 Request
- 用 $client->request('GET', '/api/posts') 发送请求——路径必须是绝对路径（以 / 开头），否则会报 InvalidArgumentException: Unable to parse URL
- 带查询参数时传数组：$client->request('GET', '/search', ['q' => 'php'])；发 JSON 数据需手动设头：['CONTENT_TYPE' => 'application/json']，并把数据作为第6个参数传入
检查响应内容与状态码要分步确认
拿到响应后不能直接读内容，得先看状态码是否符合预期，再查内容结构。空响应常因控制器没 return、异常被静默吞掉、或防火墙重定向导致。
- 先断言状态码：$this->assertSame(200, $client->getResponse()->getStatusCode())
- 再取内容：$content = $client->getResponse()->getContent()，对 JSON 响应建议用 json_decode($content, true) 后断言字段
- 若状态码非 200，用 $client->getProfile() 查调试信息，或临时关闭防火墙（如设 kernel.environment="test_no_auth"）快速定位拦截点
避免测“不该测的”：别强行单元化控制器
控制器本质是胶水代码——协调服务、调用业务逻辑、返回响应。如果里面塞了 200 行实体操作或文件生成逻辑，说明职责过重。功能测试覆盖它即可；真正要单元测试的是拆出来的服务、Repository、DTO 或领域类。
- 若坚持隔离测试控制器方法，可从容器获取实例：$controller = static::getContainer()->get('App\Controller\ApiController')，但前提是该服务未被设为私有（public: true）或已在 services_test.php 中显式暴露
- 更可持续的做法是重构：把业务逻辑移出控制器，放进独立服务，再对这些服务写纯单元测试（无内核、无 HTTP、速度快）
确保测试容器能访问私有服务
很多测试失败其实卡在容器里——比如 ServiceNotFoundException 找不到 UserRepository。这不是代码错，是测试环境容器没加载正确配置。
- 确认 config/packages/test/framework.php 中启用了 $framework->test(true)
- 关键一步：在 src/Kernel.php 的 configureContainer() 方法里，显式导入 services_test.php：$container->import($this->getConfigDir() . '/services_test.php');
- 这样 static::getContainer() 才能拿到含 test.service_container 的完整测试容器，私有服务也能被正常获取
