博客

短小实用的内容关于 Phlo 的功能：一次一个功能，并附带示例。

如果你想看看最近发生了什么，请阅读更新日志.

2026年8月6日

The frontend you do not write

A marketplace listing page is the ordinary test of a modern stack. Type in the search box and results narrow. Change the price filters and the list updates. Pick a different sort order and the rows reorder. The URL ke...

2026年8月5日

Analytics that never leave your server

Most sites answer the question "is anyone reading this" by embedding a third party on every page. That is a strange trade when you think about it: to find out how your own visitors behave, you hand each of them to a c...

2026年7月24日

一个错误页面，告诉你确切的行号，而不是猜测。

通过编译或转译代码的堆栈跟踪是一种熟悉的无用情况：行号是真实的，但它指向的是没有人手动编写的生成输出，距离你实际需要查看的源代码相差甚远。Phlo 的错误页面则指向源代码，因为解析器的构造使得这一点成为可能。

2026年7月19日

从相同模式自动生成的表单

表单通常是构建管理界面中最繁琐的部分：每个字段的正确输入、客户端和服务器验证保持同步，以及创建表单和编辑表单随着时间的推移悄然分离。在 Phlo 中，创建表单、编辑表单、列表视图和 REST API 都读取完全相同的模式，因此只有一个地方可能出现偏差。

2026年7月13日

不是玩具：四个基于 Phlo 的真实产品

展示一个演示博客和一个投票应用是一回事，而指出人们实际使用的产品则是另一回事。四个完全基于 Phlo 运行的实时产品，采用与本网站上每个示例相同的构建方式：在 .phlo 文件中定义 routes、views 和逻辑，没有单独的前端框架，也没有单独的后端框架。

2026年7月2日

与他人的 API 交谈，而无需再次编写 HTTP 粘合代码

与外部 API 的每次集成都以相同的方式开始：阅读文档，弄清楚身份验证，围绕 HTTP() 编写一个薄薄的包装，添加没有人要求的重试逻辑，直到第三次故障，然后为下一个供应商重复这一过程。Phlo 的连接器框架旨在停止重复这一部分。

2026年6月27日

一个不受供应商锁定的 WhatsApp 网关

WhatsApp 是许多小型企业实际沟通的主要渠道，但大多数自动化方式都意味着将您的消息历史、客户列表或两者都交给供应商。Phlo WhatsApp 是作为您自己运行的基础设施构建的：每个 WhatsApp 号码一个进程，使用与应用在新设备上工作相同的 QR 码登录，以及一个连接到您应用的受保护的 webhook。

2026年6月8日

视频编辑器并不是一个特殊的案例，它仍然是一个 Phlo 应用。

很容易假设一个围绕 routes、views 和数据库构建的语言适合 CRUD 应用，而对于更复杂的客户端媒体工作则显得力不从心。Phlo Presentation 部分存在就是为了验证这个假设：一个用于叙述性演示和短视频的音频时间线编辑器，完全建立在与本网站上其他所有内容相同的平台上。

2026年5月30日

没有构建工具的动物园，每个命名空间一个包，而不是每个页面一个包。

现代前端构建通常意味着一个打包工具、一个 CSS 预处理器、一个压缩工具，以及一个协调这三者的配置文件。Phlo 将所有这些功能整合到已经将 .phlo 源代码转换为 PHP 的转译器中：应用程序中的每个 <style> 和 <script> 块默认直接编译成一个共享的包，整个应用程序只有一个 app.css 和一个 app.js，这就是整个资产管道。

2026年5月16日

旨在被代理读取，而不仅仅是被代理容忍

大多数框架是为人类设计的，仅仅被一个通过它们工作的 AI 代理所容忍：猜测的约定、以训练数据截止作为真实文档的替代品、没有可靠的方法来检查更改是否确实达到了预期效果。Phlo 采取了相反的出发点：如果平台是一个闭环，只有一个真实来源，代理就可以真正理解它，而不仅仅是进行模式匹配。

2026年4月25日

一个仪表板适用于您运行的每个应用，而不是每个应用一个仪表板。

在 Phlo 中，有两个不同的东西都听起来像“管理面板”，混淆它们会造成真正的困惑，因此值得明确。Phlo Control Center 是一个小型开发面板，内置于每个应用中，当 build: true 和 debug: true 时，自动挂载在 /phlo（可以通过 control: 'admin' 移动它，或通过 control: false 关闭它）。Phlo Dashboard 是一个完全独立的应用，管理您所有应用和服务器...

2026年4月20日

架构不是文档，它是管理员。

大多数管理面板在数据模型已经存在后会手动构建第二次：这里一个列表视图，那里一个表单，API 和 UI 之间的验证重复。Phlo CMS 从这一点出发，认为这是浪费精力。您只需声明一次数据的外观，CMS 就会生成其余部分。

2026年3月27日

守护进程：温暖的工作者，无启动成本

每个 PHP 请求在进行任何实际工作之前，传统上都需要支付一个小的税费：引导框架，连接应用程序，然后处理请求。FrankenPHP 的 worker 模式已经通过在请求之间保持应用程序驻留在内存中，去除了大部分开销。Phlo Daemon 采用了相同的理念，并将其扩展到所有非正常的 HTTP 请求。

2026年3月19日

Phlo Realtime：无需离开语言即可使用 WebSockets

大多数框架将实时视为附加在第一层上的第二个堆栈：一个单独的 WebSocket 服务器，一个单独的事件总线，以及一个单独的“推送内容”的思维模型。相反，Phlo Realtime 的构建是为了实现增量式的。一个 Phlo 应用在 Phlo Daemon 运行时是一个正常的请求-响应应用，只有在那时，实时层才会被激活。

2026年2月24日

租用容量的终结：通过 Phlo 重新掌控全栈

Web开发正处于复杂性危机的中心。宣传一直是“行业标准”要求导航依赖树，深到无法审计，以及框架的更新速度快到任何人都无法掌握。在这个过程中，我们接受了一种租用能力的模型，其中云原生默认设置让托管费用在产品成功时向上弯曲。

2026年2月16日

理智的架构：为什么 Phlo 的极简主义是全栈的未来

现代网页开发已经陷入了长达十五年的争论，这使我们进入了一个复杂性陷阱。我们用服务器端 PHP 的经过验证的稳定性（它仍然默默地支持着 70% 的网络）交换了一个碎片化的世界，充满了水合不匹配、脆弱的构建链和没有任何单一架构师能够真正审计的依赖树。典型堆栈的层之间的距离已经变得如此之大，以至于没有人再能在脑海中持有整个图景。