Blade实现Twig include的ignore missing等效功能的方法

Blade原生@include本身已经支持按顺序查找候选模板、注入自定义变量、按需关闭父作用域继承这些和Twig一致的能力，唯一的功能缺口是：当传入的候选模板数组全部不存在时，原生会直接抛出「视图不存在」的异常，这正是需要补齐的ignore missing逻辑。 #

核心实现逻辑 #

不需要从零开发视图加载流程，直接复用Laravel自带的视图工厂能力即可：

1. 封装可容错的核心渲染逻辑，写一个全局辅助函数：

function include_ignore_missing(array $candidateViews, array $data = [], bool $only = false)
{
    $viewFactory = app('view');
    // 按传入顺序依次检查模板是否存在
    foreach ($candidateViews as $viewName) {
        if ($viewFactory->exists($viewName)) {
            // 找到第一个存在的模板直接渲染，按规则处理only参数
            return $only
                ? $viewFactory->make($viewName, $data)->render()
                : $viewFactory->make($viewName, array_merge($viewFactory->shared(), $data))->render();
        }
    }
    // 所有候选模板都找不到时，直接返回空字符串，不抛任何异常
    return '';
}

把这个函数放到项目的helper文件中，添加到composer的自动加载列表即可全局使用。 #

注册自定义Blade指令对齐模板调用体验 #

在AppServiceProvider的boot方法里注册新的Blade指令，让模板调用和原生语法保持一致：

\Blade::directive('includeIgnore', function ($expression) {
    // 拆分传入的多段参数，兼容不同调用形式
    $params = array_map('trim', explode(',', $expression));
    $candidates = $params[0] ?? '[]';
    $injectData = $params[1] ?? '[]';
    $enableOnly = $params[2] ?? 'false';

    return "<?php echo include_ignore_missing({$candidates}, {$injectData}, {$enableOnly}); ?>";
});

注册完成后，模板中的调用形式和Twig的三个场景完全一一对应：

• 对应无额外变量、仅忽略缺失的场景，直接传候选模板数组：

  @includeIgnore(['partials/A', 'partials/B'])
  

• 对应带自定义变量注入、忽略缺失的场景，第二个参数传入要注入的键值对：

  @includeIgnore(['partials/A', 'partials/B'], ['foo' => 'bar'])
  

• 对应仅使用注入变量、不继承父作用域、忽略缺失的场景，第三个参数传true开启only模式：

  @includeIgnore(['partials/A', 'partials/B'], ['foo' => 'bar'], true)
  

实操实用技巧 #

• 临时使用、不需要全局封装的场景，可以直接用Blade原生语法拼出等效效果，不需要修改任何服务配置：

  @php($targetView = collect(['partials/A', 'partials/B'])->firstWhere(fn($view) => view()->exists($view)))
  @if($targetView)
      @include($targetView, ['foo' => 'bar'])
  @endif
  

• 视图路径完全遵循Blade原生规则，把Twig模板的路径对应替换为resources/views下的相对路径即可，不需要额外做路径映射。
• 如果你确实想贴近之前推导的带ignore missing关键字的写法，可以调整Blade指令的正则解析规则，对传入参数里的关键字做过滤处理，但这种写法的可读性比显式传参差，后续维护成本更高，更推荐使用参数化的调用形式。

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