application目录存放业务逻辑代码（控制器、模型、视图、配置等），不直接对外访问，静态资源须放public/static/；public是唯一Web入口，含index.php和静态资源；runtime需可写以生成缓存日志；vendor存Composer依赖，extend放自定义扩展类。
application目录到底放什么，别和public搞混了
ThinkPHP的application目录是业务逻辑的主战场，不是静态资源存放地。它默认不直接对外访问，所有HTTP请求必须经由public/index.php入口转发进来。如果你把CSS、JS或图片丢进application里，浏览器会404——因为Web服务器（如Nginx/Apache）通常已配置禁止访问该目录。
常见错误：把application/index/view/index/index.html当成可直连的HTML文件去打开，结果看到原始代码或报错。实际它得靠控制器调用view()方法渲染，且模板路径由框架自动解析。
-
application/index/是模块名，不是必须叫index，可按业务建admin、api - 控制器类必须放在
controller子目录下，且文件名与类名严格一致（如Index.php→Index类） - 配置文件
application/config.php只影响当前应用，多应用模式下各模块可有独立配置
public目录为什么不能删，它承担了哪些关键职责
public是唯一被Web服务器公开的入口目录，ThinkPHP的安全边界就划在这里。删掉它或把index.php挪到别处，会导致路由失效、静态资源404、甚至暴露application源码。
典型问题：本地开发时用php内置服务器（php -S localhost:8000）直接跑index.php，却忘了指定路由器脚本，结果路由规则不生效——因为内置服务器不会自动读取public/.htaccess或Nginx的rewrite规则。
立即学习“PHP免费学习笔记（深入）”；
-
public/static/存放CSS/JS/图片等，URL路径就是/static/css/app.css -
public/index.php加载框架并执行think\App::run()，是整个请求生命周期的起点 - 如果启用
APP_DEBUG=false，错误日志默认写入runtime/log/，而非显示在页面上
runtime目录权限不对会直接导致白屏
runtime是ThinkPHP运行时自动生成缓存、日志、模板编译文件的地方。它必须可写，否则首次访问就会卡在“无法生成缓存”上，页面空白且无提示（尤其APP_DEBUG=false时）。
容易踩的坑：部署到Linux服务器后，用root用户解压代码，但Web进程（如www-data、nginx）没有runtime目录的写权限；或者Windows下共享目录挂载到Linux，导致SELinux或挂载参数禁用了写入。
- 确保
runtime及其子目录（cache、log、temp）对Web服务器用户可读写 - 开发阶段可临时设为777验证问题，上线前务必收紧权限（如755+属组正确）
- 若用Docker，需在
Dockerfile中明确chown www-data:www-data runtime
extend和vendor目录分工要分清
vendor是Composer管理的第三方依赖（如topthink/think-orm），不要手动改里面任何文件；extend是你自己写的扩展类库，比如封装的微信SDK调用类、通用Excel导出工具，它会被自动加载（只要命名空间和路径匹配）。
混淆后果：把自定义类扔进vendor，下次composer update直接覆盖丢失；或者把extend里的类命名空间写成think\开头，导致和核心类冲突。
-
extend下的类需遵循PSR-4规范，例如extend/mylib/Wechat.php对应命名空间mylib - 在
application/config.php中可通过extra_config_list引入extend里的配置文件 - 不建议在
extend里重写think命名空间下的类，优先用中间件或事件替代
目录结构不是摆设，每个位置背后是框架的加载顺序、安全策略和运行时约定。动一个目录前，先看它被谁读、谁写、谁依赖——比死记硬背路径更重要。
