首页 / 开发文档 / 整体架构

整体架构

一次请求经过了哪些环节,以及几个关键设计决策背后的原因。

一次请求的路径

浏览器请求
   ↓
wwwroot/index.php        唯一入口
   ↓
App::boot()              读配置、设时区、启会话、发安全响应头
   ↓
App::dispatch()          解析路径段 → 白名单校验 → 授权闸门
   ↓
FrontController          取数 + 渲染
   ↓
Template                 编译模板(有缓存)→ 输出

几个关键决策

1. 内核在网站根目录之外

源码、配置、数据库都不在能被 HTTP 访问的位置。 不依赖任何服务器拦截规则 —— 规则会写错,文件不在那里则不存在写错的可能。

2. 数据库唯一合法出入口是数据层

整个项目里只有数据层这一个文件允许出现 SQL,且所有外部输入一律走参数绑定。 模板层在语法上就无法拼接 SQL。

3. 模板编译成 PHP 后缓存

模板第一次访问时编译成 PHP 文件缓存起来,之后直接执行。 改了模板会自动重新编译,不需要手动清缓存。

4. 字段定义是数据,不是表结构

自定义字段不落到数据库列上,所以加字段不需要结构变更,也没有迁移风险。

5. 授权离线校验

非对称签名,本地验证,不联网回调。站点在完全隔离的网络里也能正常运行。

分层职责

层职责不该做的事
内核 core/路由、取数、模板引擎、权限、授权、更新不含任何具体站点的业务逻辑
控制器 app/组装数据、决定渲染哪个模板不写 HTML
模板 templates/只负责展示不查库、不做业务判断
没找到答案? 可以在 联系我们 留言说明使用场景,我们会补充进文档。