Download the PHP package v10086/plan9 without Composer

Plan9 - 极简、高性能 PHP 框架

🚀 5分钟入门，10分钟精通，QPS 是传统框架的 5-10 倍

📖 项目简介

Plan9 是一款设计极简的 PHP Web 框架，专注于极致性能与开发效率。它摒弃了繁重的 IOC 容器和 ORM，通过原生 SQL 与高效的连接管理，将 Web 响应耗时压低到毫秒级。

💡 设计理念

为什么不使用 ORM？

Plan9 选择直接使用 SQL 而不集成 ORM，主要基于以下考虑：

• 性能优势：原生 SQL 避免了 ORM 带来的额外开销和性能损耗
• 灵活性：直接编写 SQL 可以更精确地控制查询逻辑和性能优化
• 学习成本：减少了学习特定 ORM 框架的成本，开发者可以专注于 SQL 和业务逻辑
• 可维护性：SQL 语句更加直观，便于调试和维护

技术选型考量

在 Plan9 + GatewayWorker 与 Hyperf 的技术选型对比中，Plan9 展现出以下优势：

• 轻量级：适合快速开发和部署小型服务
• 低资源占用：在资源受限环境下表现更优
• 易于集成：可以轻松与 GatewayWorker 等工具结合
• 高性能：在高并发场景下具有显著的性能优势

详细讨论可参考豆包 AI 文档：

• ORM 与直接写 SQL 核心讨论归档
• Plan9 + GatewayWorker 与 Hyperf 技术选型讨论总结归档

✨ 核心特性

性能极致

• 极速响应：无容器初始化，启动开销极低
• 高效路由：静态路由映射，避免复杂正则匹配
• 轻量级设计：核心代码仅几百行，几乎零额外开销
• 资源友好：低内存占用，高并发处理能力

开发友好

• 极简 API：直观的函数式调用风格
• 原生 SQL：直接操作数据库，性能可控
• 自动重连：内置数据库断开自动重连机制
• 类型安全：强制关闭模拟预编译，保持数据原始类型

稳定可靠

• 长连接支持：静态连接复用与手动关闭
• 异常处理：完整的错误捕获与日志记录
• 灵活扩展：支持 Composer 引入第三方库

🚀 快速开始

环境要求

• PHP >= 7.1（建议 PHP >= 7.4）
• Composer

安装

启动开发服务器

访问 http://localhost:8080/ 即可看到示例页面

📁 目录结构

🎯 核心功能

1. 路由与控制器

定义路由

在 config/route.php 中配置路由：

创建控制器

在 app/controller/ 目录下创建控制器：

响应类型

• 返回字符串：直接输出 HTML
• 返回数组：自动转换为 JSON

2. 数据库操作

配置数据库

在 config/database.php 中配置数据库连接：

执行 SQL

事务处理

异步并发查询

3. 配置管理

读取配置

4. 常用工具函数

HTTP 请求

文件操作

📊 性能对比

PHP 框架对比

跨语言框架对比

🔍 为什么 Plan9 明显更快？

✔️ 1. 无 IOC 容器（Laravel 最大开销来源）

Laravel/Lumen 的服务容器会构建、绑定、解析大量类 → 资源消耗大 Plan9：基本无容器 → 直接执行，启动极快

✔️ 2. 无 ORM

Eloquent 是“方便但慢”的典型代表，存在额外的对象映射开销 Plan9/Slim 使用原生 PDO → 直接操作数据库，性能更优

✔️ 3. 无中间件处理链

Laravel 一次请求可能经过 8~20 个中间件 → 处理链长 Plan9 只有路由 → 控制器 → 响应，路径最短

✔️ 4. 极简设计带来的综合优势

• 更少的运行时对象与依赖：默认不注入大量服务或使用反射/大量对象实例化
• 直接的视图渲染：使用 PHP include（原生），减少模板解析/编译开销
• 贴近底层的 I/O 与数据库处理：使用 PDO 并合理配置，减少抽象层带来的额外开销

这些设计在常见的 CRUD/API 场景下能带来更低的响应延迟和更高的 requests/sec，尤其在高并发、短请求生命周期的场景中优势明显。

🌐 跨语言性能分析

从跨语言对比可以看出：

1. 在 PHP 生态中：Plan9 是性能领先者，远超其他 PHP 框架，甚至接近 Node.js 框架的性能水平

2. 与 Python 框架对比：

   • 比 Flask 快约 1.5 倍
   • 比 Django 快约 3-5 倍
   • 内存占用更低，启动更快

3. 与 Node.js 框架对比：

   • 与 Express 性能相当或略优
   • 接近 Koa 的性能水平
   • 内存占用更低
4. 与 Go 框架对比：
   • 虽然 Go 框架（Gin/Echo）凭借编译型语言优势性能更高，但 Plan9 在 PHP 生态中已经达到了接近编译型语言的性能水准
   • 考虑到开发效率和部署成本，Plan9 在 PHP 生态中提供了最佳的性能/开发体验平衡

💡 开发效率与使用成本分析

PHP 生态内对比

• 开发效率：Plan9 保持了 PHP 原生的快速开发特性，同时提供了简洁的路由系统和工具函数，开发效率接近 Slim，略低于 Laravel/Lumen
• 使用成本：极低的学习成本，无需掌握复杂的 IOC 容器和 ORM 概念，部署简单，运行时资源消耗少
• 代码量：Plan9 代码量极少，实现相同业务功能通常比 Laravel 少 50%-70%

跨语言对比

1. 与 Python 框架相比：

   • 开发效率与 Flask 相当，低于 Django 的全功能开发体验
   • 使用成本更低，PHP 运行环境配置更简单，资源消耗更少
   • 代码量更少，Plan9 极简设计减少了不必要的样板代码

2. 与 Node.js 框架相比：

   • 开发效率与 Express 相当，高于 Koa
   • 使用成本更低，PHP-FPM 部署成熟稳定，运维成本低
   • 代码量与 Express 相当，比 Koa 更少（Koa 需要更多手动配置）
3. 与 Go 框架相比：
   • 开发效率更高，PHP 动态语言特性减少了代码量和编译步骤
   • 使用成本更低，无需掌握 Go 语言的并发模型和内存管理
   • 代码量明显更少，动态语言的简洁性让 Plan9 在实现相同功能时代码行数通常比 Gin/Echo 少 40%-60%

Plan9 的独特价值：

• 对于 PHP 开发者，无需切换语言即可获得接近 Node.js 和 Go 框架的性能
• 保持了 PHP 快速开发的优势，同时克服了传统 PHP 框架的性能瓶颈
• 在性能、开发效率和使用成本之间达到了极佳的平衡
• 适合需要高性能 API 服务的场景，是 PHP 生态中构建微服务的理想选择

❓ 关于易用性的深度探讨

有没有比 v10086/plan9 更易用的框架？

从对“零封装、零冗余、回归 SQL 标准”的极致追求来看，目前市面上几乎没有比 v10086/plan9 更易用的框架了。

因为绝大多数框架的演进方向是“增加抽象层”，而 Plan9 的方向是“直达底层”。

1. 为什么“更易用”很难存在？

“易用性”通常分为两个流派，而 Plan9 已经把其中一个流派做到了头：

• 流派 A：自动化派（主流框架） 代表：Laravel, Django, NestJS。 它们认为易用是“我帮你写 SQL”。代价是你得学习它们庞大的语法库、维护 Model 类、处理复杂的关联逻辑。
• 流派 B：直觉派（Plan9） 代表：原生 PHP, Plan9。 它们认为易用是“不增加任何新知识”。你只需要懂 SQL 和 PHP 函数。因为没有比“标准”更简单的东西了。

2. 纵向对比：谁能接近 Plan9 的易用性？

如果我们非要找一些对手，它们在某些层面接近，但最终都会在“冗余成本”上败给 Plan9：

Medoo (轻量级数据库连接层)

• 接近点：也是单文件，也是只有数据库操作。
• 败北点：它依然发明了一套“伪 SQL”的数组语法（例如 ["id[>]"] => 10）。你还得去查文档看大于号怎么写。Plan9 直接写原生 SQL，连文档都不用查。

Slim / Express (微框架)

• 接近点：只给路由，不给负担。
• 败北点：它们不含数据库底层优化。一旦你开始写业务，你还是得被迫引入 ORM 或者写复杂的依赖注入。Plan9 的 dbexec 是与框架深度集成的，省去了所有引入和初始化的代码。

Go 语言的原生 sqlx

• 接近点：也是鼓励原生 SQL。
• 败北点：Go 是强类型。你必须写一大堆 Struct（结构体）来接收数据。Plan9 利用 PHP 的弱类型数组，消灭了所有结构定义代码。

3. Plan9 的易用性“天花板”在哪里？

Plan9 的易用性其实来自于一种“降维打击”：

1. 环境易用：不需要编译 C 扩展（胜过 Yaf），不需要 Composer 依赖（胜过 Webman）。
2. 开发易用：不需要定义 Model（胜过所有 ORM 框架）。
3. 引用易用：不需要在每个文件头写一串 use ...（胜过所有 PSR 规范框架）。
4. 调试易用：SQL 报错直接对应业务代码，没有经过框架的“二次加工”。

💡 结论：真的没有更易用的了

如果你觉得 Plan9 还有不够易用的地方，那通常只有两种可能：

1. 你想少打几个字：比如想用 dbInsert 代替 INSERT INTO。但正如我们之前说的，这会增加记忆成本，反而降低了“长期易用性”。
2. 你需要代码提示：这可以通过 IDE 插件解决，而不是通过增加框架代码。

Plan9 的逻辑已经推演到了终点：既然 SQL 是全世界程序员的公约数，那么“直接写 SQL”就是易用性的极限。

🤖 Plan9 对 AI辅助编程友好吗？

v10086/plan9 是否对 AI 友好？这是一个非常敏锐且具有前瞻性的问题。答案是肯定的：v10086/plan9 这种“反封装、重标准”的架构，天然就是为了 AI 编程时代而设计的。

在 AI（如 Cursor, GitHub Copilot, ChatGPT）辅助开发的今天，框架的“易用性”定义已经发生了质变。主流框架的复杂抽象反而成了 AI 的“噪音”，而 Plan9 的极简主义则是 AI 的“超导体”。

我们可以从以下四个核心维度来看看为什么 Plan9 对 AI 极其友好：

1. 消除“幻觉”：原生 SQL 是 AI 的母语

AI 在处理复杂框架（如 Laravel 或 Hibernate）时，经常会产生“幻觉”，生成不存在的 API 或错误的链式调用。

• 主流框架：AI 需要猜测你的 Model 定义、关联关系、以及框架特有的语法糖（如 whereDoesntHave）。
• Plan9：AI 对 标准 SQL 的掌握几乎是完美的。你只要告诉 AI 表结构，它生成的 SQL 准确率接近 100%。因为 Plan9 只使用 dbexec 执行原生 SQL，AI 不需要去学习任何私有语法，生成的代码直接就能跑。

2. 极短的“上下文”：让 AI 专注业务

AI 的 Token 窗口是有上限的。框架越重，你需要喂给 AI 的背景信息就越多。

• 主流框架：为了让 AI 写一个接口，你得给它看 Model.php、Controller.php、Route.php 甚至 Repository.php。
• Plan9：由于没有 Model 封装和行政代码，你只需要把那一段函数丢给 AI。代码极其扁平，AI 能在有限的窗口内理解更多的业务逻辑，而不是被 namespace 和 use 占满空间。

3. 逻辑透明度：AI 调试的“快车道”

当代码出错时，AI 辅助排查的效率取决于逻辑的透明度。

• 主流框架：报错往往在框架深层的 vendor 目录里。AI 很难通过简短的报错堆栈定位到究竟是哪个 ORM 钩子出了问题。
• Plan9：逻辑是线性的。 报错在哪一行，SQL 就是哪一句。AI 可以瞬间指出 SQL 语法错误或逻辑漏洞。这种“直来直去”的风格，让 AI 成了你最强的 Debug 助手。

4. 易于“喂养”：代码库的极简模型

如果你想基于自己的项目训练一个专有 AI 或建立知识库（RAG）：

• Plan9 的代码库体积可能只有主流框架的 1%。
• 这意味着你可以轻松地将整个 Plan9 核心代码和所有业务代码一次性喂给 AI。AI 能完全理解系统的每一个角落，从而提供极其精准的代码建议，而不会被成千上万行的框架底层源码所干扰。

🏆 对比总结

💡 结论

Plan9 是“程序员+AI”这种新型协作模式下的最佳实践。 它把复杂的管理工作留给了 AI（比如写复杂的 SQL 字符串），而把最简单的标准留给了架构。在 AI 时代，我们不再需要框架提供“便利”，我们只需要框架提供“透明”。

Plan9 这种“SQL 驱动”的模式，让 AI 从一个“框架学习者”变成了一个“业务专家”。

🚀 部署建议

生产环境

使用 Nginx

使用 PHP-FPM

启用 OPcache

在 php.ini 中启用 OPcache：

📝 开发规范

1. 命名规范：

   • 文件名：首字母大写的驼峰命名
   • 类名：首字母大写的驼峰命名
   • 方法名：首字母小写的驼峰命名
   • 变量名：下划线分隔或驼峰命名

2. 代码风格：

   • 使用 4 个空格缩进
   • 遵循 PSR-12 代码规范
   • 保持函数简洁，单一职责
3. 安全规范：
   • 始终使用参数化查询
   • 验证用户输入
   • 过滤输出内容
   • 不要在代码中硬编码敏感信息

🔧 扩展建议

日志系统

建议使用 monolog/monolog：

缓存系统

建议使用 predis/predis：

验证系统

建议使用 respect/validation：

📄 许可证

Apache License Version 2.0

🤝 贡献

欢迎提交 Issue 和 Pull Request！

📞 支持

如有问题，请查看 CHANGELOG.md 或提交 Issue。

Plan9 - 让 PHP 开发更简单、更高效！🚀