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

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

没有预处理器税的 CSS

<style>
.card {
    background: $surface
    border: 1px solid $border
    .card-title {
        color: $primary
    }
}
.card:hover: border-color: $primary
</style>

没有分号，真实的嵌套，单个声明的一行形式，以及每个活动主题解析的 $name 变量，编译为真实的 CSS 自定义属性。运行时没有 CSS-in-JS 的成本，浏览器端也没有解释这种语法，转译器在发货时已经完成了工作。

每个命名空间一个包，而不是每个页面一个包

默认情况下是一个单一的 app.css/app.js 配对，但这并不是一个硬编码的规则：一个 <style> 或 <script> 块可以通过 ns= 选择不同的命名空间，而 data/app.json 控制映射。这个站点实际上使用了这个：主页面共享 app.css/app.js，但语法高亮器和演示播放器各自获得自己的包，因此一个较重、加载频率较低的代码片段不会出现在每个页面的默认下载中。重点从来不是“无论如何都只有一个文件”，而是一个页面加载其命名空间实际需要的一到两个包，而不是为每个页面组装的定制包，也不是可以悄然与页面使用的内容不同步的十几个小样式表。

收益体现在哪里

在 build::run 时间构建一次并发货一小组稳定的可缓存包，是不在第一时间发货构建工具动物园的结果：没有只需要三个类的组件库中的未使用 CSS，没有来自不匹配的打包器配置的重复 polyfills，没有在页面交互之前需要水合的框架运行时。无论应用是一个五路由的原型还是管理车队的 Dashboard，构建都是相同的，因为只有一个管道，tour.phlo.tech，一个未修改的 Phlo 应用，在正是这个管道上在 Lighthouse 的四个审计中得分 100 分。

哪里可以阅读更多

指南中的性能章节更深入地涵盖了机制：CSS 转译器如何按主题解析变量，配置章节中的命名空间/包模型，以及构建在 release/www/ 下实际生成的内容以供生产使用。