Statamic中选用Antlers而非Blade的原因？使用Blade会遇哪些问题？

一、会缺失的核心功能 #

• Antlers原生的Bard块自动上下文绑定能力：Antlers的{{ block:myField }}会自动处理Bard字段内不同块类型的作用域，嵌套块、重复块的上下文会自动继承，无需手动传参。自行实现Blade组件时需要手动传递所有嵌套上下文，多层嵌套场景下开发量会陡增。
• Bard内置的动态修饰器支持：Antlers可直接给字段加修饰器实现快速处理，比如{{ block:text | markdown | truncate:100 }}，Blade中直接调用{{ $myField }}的话，这些修饰器要么需要手动实现，要么要额外调用Statamic的修饰器方法，写法会繁琐很多。
• 控制台预览模式的实时联动：Statamic控制台下的内容预览、实时编辑功能对Antlers写的Bard块原生支持热更新，纯Blade实现的组件大概率会出现预览和实际渲染不一致、实时编辑不生效的问题，需要额外写适配逻辑。
• 多站点/多语言的自动翻译处理：Antlers会自动匹配当前站点的语言上下文输出对应翻译的字段值，纯Blade直接取$myField很可能只会取到默认语言的内容，需要手动指定当前站点的locale参数。
• Bard专属的条件渲染语法糖：Antlers针对Bard块的if exists、unless empty、嵌套块循环遍历的语法非常简洁，Blade中需要自己写isset、empty判断，还要额外处理Statamic字段返回的Collection结构遍历逻辑，代码冗余度会高很多。

二、意料之外的常见问题 #

• 复杂Bard结构解析异常：如果Bard里包含set块、嵌套列表、媒体块、引用块这类复杂结构，直接取$myField大概率只会拿到原始数组结构，不会自动渲染为HTML，需要手动处理每种结构的渲染逻辑，漏处理任意一种块类型就会出现空白、乱码问题。
• 额外性能损耗：Antlers底层已经针对Statamic的字段结构做了大量缓存优化，纯Blade实现如果没有手动做对应缓存，多字段、多嵌套的页面加载速度会比Antlers实现慢30%以上，访问量高的时候性能问题会更明显。
• 版本升级兼容性差：Statamic每次大版本升级都会调整Bard字段的返回结构、内置方法，Antlers的写法官方会保证向前兼容，但是自行实现的Blade组件很可能升级后直接报错，需要每次升级都手动调整适配。
• 安全过滤失效风险：Statamic默认会对Antlers输出的内容做XSS过滤、恶意代码拦截，如果你在Blade中直接用{{ $myField }}输出，没有手动调用Statamic的内容净化方法，会存在XSS安全隐患。
• 第三方插件适配缺失：绝大多数Statamic的Bard扩展插件都是基于Antlers做适配，纯Blade开发场景下这些插件的功能都无法直接调用，需要自行编写兼容逻辑。

内容的提问来源于stack exchange，提问作者Toskan