#背景
这不是一个"要替代 Laravel"的框架。它解决的是一个具体问题：给中小型内容站与企业官网一套自己能完全读懂的底座。
用过框架的人都有过这种时刻：出问题时顺着调用栈翻了十几层 vendor 代码，最后发现是某个包对 PHP 版本的假设过期了。对独立开发者来说，这种"排障时间"比"开发时间"更贵。
#1.0 意味着什么
能力对齐（够用即止，不做全家桶）：
| 模块 | 能力 |
|---|---|
| 路由 | 参数绑定、分组中间件、路由缓存、301 规范化 |
| 容器 | 构造器与 setter 注入、单例、接口绑定 |
| 数据库 | 查询构造器、迁移与回滚、SQLite/MySQL 双驱动、软删除 |
| 模板 | 原生 PHP 模板 + 布局/片段/include、自动转义 |
| 后台 | RBAC 多角色、操作审计、内容备份还原、数据字典 |
| 前端 | 服务端渲染 + 原生 CSS/ESM，零构建链 |
质量门槛（每次改动都要过）：
php vabora check # 220 个文件：语法、禁用函数、弃用 API、@ 抑制符
php vabora test # 120 个用例 / 1528 条断言
php vabora health # 10 项上线巡检check 不只是语法检查——它禁掉了 @ 错误抑制符与已弃用函数。这两条不是洁癖：@ 会让真实错误静默，弃用函数会在下次 PHP 升级时集中爆炸。
体积与性能（实测，非估算）：
- 前台 CSS + JS 原始 114 KB、gzip 后 28 KB，无前端框架；
- 首页 HTML 43 KB、gzip 后 9.8 KB；
- SQLite 100 并发 1000 次请求：P95 88ms、写入零丢失（
journal_mode=WAL+busy_timeout=5000）。
#1.0 之后的三件事
- PHP 版本：最低 8.2，推荐 8.3+。用到的特性都是稳定特性（枚举、只读属性、
match），不追实验语法。 - 升级策略：迁移文件可回滚，
php vabora migrate:rollback一步退回；数据库切换用database:switch（自动备份 + 迁移数据）。 - 许可：自用与客户交付均为闭源可商用；不提供 SaaS 多租户能力。
#什么时候不该用它
- 需要大团队并行开发：生态、约定、现成轮子（队列、支付、权限生态）带来的协作效率，自研框架比不了；
- 需要复杂异步/高并发：PHP 常驻内存方案（Swoole/RoadRunner）与队列体系更合适；
- 想少写代码：Laravel 的 Rails 式便利是它的核心价值，自研框架倾向于"少一层黑盒"，两者取向不同。
#取舍
- 不做插件市场：生态是需要投入的长期合同，一个人维护不了；
- 不为兼容牺牲清晰：1.0 前做过几次破坏性调整，换来的是现在没有历史包袱；
- 性能目标定在"不拖后腿"而不是"最快"：从 300ms 优化到 30ms 对转化率的影响远小于从 3s 优化到 300ms；把精力放在内容与体验上更划算。
评论
还没有评论，来说点什么吧。