src目录专用于存放可自动加载的PHP类，路径与命名空间必须严格对应；var是临时工作台，缓存日志位置受环境和配置控制；public是唯一Web服务器应访问的入口。
src 目录不是“源码随便放”的地方
它专用于存放你写的可 autoload 的 PHP 类，路径和命名空间必须严格对应。Symfony 不会自动扫描 src/Utils/Helper.php 这类“非标准”位置的文件，除非你手动配置 PSR-4 映射。
常见错误现象：Class "AppUtilsHelper" not found，其实文件就在那里，只是命名空间写成 namespace Utils; 或路径没对齐。
- 标准写法：文件
src/Utils/Helper.php→ 命名空间必须是namespace AppUtils; -
composer.json中的 PSR-4 配置不能删或改错，典型值是"App\": "src/" - 改完命名空间或移动文件后，必须运行
composer dump-autoload，否则 autoloader 不更新
var 目录是 Symfony 的“临时工作台”，不是日志/缓存的最终归宿
它默认包含 cache/、log/、public/（开发时）等子目录，但这些内容在生产环境可能被移到别处 —— 比如用 APP_ENV=prod 时，缓存路径实际由 kernel.cache_dir 参数控制，未必还在 var/cache。
容易踩的坑：直接把 var/log 挂载为只读卷，结果 dev.log 写失败；或清缓存只删 var/cache/dev 却忘了 var/cache/prod 也存在。
-
var/cache是 Symfony 编译容器、模板、路由等生成的 PHP 文件，每次改配置/路由都要清它 -
var/log默认用Monolog写日志，但日志轮转、大小限制靠monolog.handler.main配置，不是靠文件系统 - 部署时建议用
bin/console cache:warmup --env=prod预热，而不是依赖首次访问触发生成
public 目录是唯一该被 Web 服务器直接访问的入口
里面只有 index.php（前端控制器）、index_dev.php（开发用）、静态资源（CSS/JS/images）和 robots.txt。所有请求都必须经由它进入内核，不能绕过。
常见错误：把 assets/ 放进 src/，再用 asset() 函数引用 —— 开发时能显示，部署后 404，因为 Web 服务器根本看不到 src/。
- 静态资源必须放在
public/下，或通过assets:install命令软链到public/assets/ -
index.php里调用Kernel::getEnvironment()决定加载哪个环境配置，别手改它来“切环境” - Nginx/Apache 配置必须指向
public/，不是项目根目录，否则.env可能被直接下载
config 和 templates 目录的加载顺序影响实际行为
Symfony 按环境 + 继承顺序加载配置：config/packages/*.yaml → config/packages/<env>/*.yaml</env> → config/services.yaml。同名参数或服务定义，后加载的会覆盖前面的。
比如你在 config/packages/dev/debug.yaml 里设了 debug: true，但在 config/services.yaml 里又写了 parameters: { debug: false }，那最终值是 false —— 因为 services.yaml 总是最后加载。
-
templates/下的 Twig 文件按templates/bundles/→templates/→vendor/覆盖优先级查找 - 自定义异常页面要放
templates/bundles/TwigBundle/Exception/，不是templates/Exception/ -
config/bundles.php控制哪些包被启用，删掉某行 ≠ 卸载包，只是不注册其扩展
