symfony 7延续symfony 6目录结构但强化显式配置：services.yaml需手动启用、kernel构造函数移除默认参数、bundles.php注册受kernel.mode影响、控制器须标注#[ascontroller]。
Symfony 7 并没有引入“全新目录结构”，也没有强制迁移旧项目目录。它延续了 Symfony 6 的标准布局，但对核心组件的组织方式、默认配置加载逻辑和可选模块的启用机制做了实质性精简——这直接影响你日常开发时“该改哪”“该删什么”“为什么删了反而报错”。
service.yaml 不再自动加载，framework 配置需显式声明
从 Symfony 7 开始，config/services.yaml 默认不再被框架自动包含，除非你在 config/packages/framework.yaml 中明确启用它：
framework: # ... 其他配置 services: true # ← 必须加这一行，否则 services.yaml 被忽略
不加这行的结果是：自定义服务无法注册、bind 失效、defaults 作用域丢失。很多升级后报 ServiceNotFoundException 的案例，根源就在这里。
原因在于 Symfony 7 推行“按需加载”原则：如果你用的是轻量内核模式（kernel.mode: 'light'），连 framework 组件本身都可能被禁用，更不会自动拉入 service 定义。
src/Kernel.php 的构造函数签名变更，$environment 和 $debug 不再可选
Symfony 7 要求 src/Kernel.php 构造函数严格匹配新签名：
public function __construct(string $environment, bool $debug)
旧写法（带默认值）会直接导致启动失败：
// ❌ 错误示例（Symfony 7 拒绝） public function __construct(string $environment = '', bool $debug = false)
这是因为 Symfony 7 的运行时（symfony/runtime）在实例化 Kernel 前已确定环境与调试状态，不再允许 Kernel 自行推断。升级时务必检查并移除默认参数。
config/bundles.php 中的 Bundle 注册逻辑更敏感
Bundle 是否生效，现在不仅取决于是否在 bundles.php 中列出，还受当前环境和 kernel.mode 影响。例如：
-
SensioFrameworkExtraBundle在kernel.mode: 'light'下会被自动跳过，即使它在bundles.php里 -
TwigBundle若未显式配置templating: ~，且kernel.mode为light，则完全不加载 Twig 服务
这意味着：你不能只靠 bundles.php 判断某个功能是否存在；必须结合 config/packages/*.yaml 和内核模式一起看。常见陷阱是本地开发启用了 Bundle，但生产部署用了 light 模式，结果模板渲染直接 500。
src/Controller/ 不再是唯一控制器路径，但 #[AsController] 成为硬性要求
Symfony 7 允许控制器放在任意命名空间（如 App\Infrastructure\Http），只要类上标注了 #[AsController]：
#[AsController]
class ApiUserController { /* ... */ }
但反过来说：哪怕你把类放在 src/Controller/ 下，没加这个属性，路由匹配也会失败（Controller does not exist）。这是为了强制显式声明控制器边界，避免自动发现带来的性能与歧义问题。
另外，AbstractController 的快捷方法（如 render()、json()）现在依赖注入了 RequestStack 和 RouterInterface，如果这些服务被禁用（比如在 light 模式下删了 router 配置），调用就会抛出异常——不能只看目录位置，得看服务图谱是否完整。
真正容易被忽略的点是：所有“精简”都建立在“显式优于隐式”的前提上。Symfony 7 不再替你猜意图，而是把决策权交还给配置和注解。删一个 YAML 键、少写一个 attribute、漏配一个布尔开关，都可能让整条请求链路静默中断。
