应使用 @php … @endphp 包裹原生 PHP 代码，不可直接书写；仅限临时计算等极少数场景，禁止数据库查询或复杂逻辑；变量可在后续 Blade 指令中使用，输出统一用 {{ }}；推荐用 Blade 指令或组件替代 @php。
直接用 @php … @endphp 包裹原生 PHP 代码
Blade 允许你在模板中写原生 PHP，但必须用 @php 和 @endphp 指令包裹，不能直接写 <?php ... ?> —— 后者会被当成纯文本输出，甚至可能暴露敏感逻辑或导致解析错误。
常见错误现象：页面上直接显示 <?php echo $x; ?> 字符串，或报错 ParseError: syntax error。
-
@php块内可声明变量、调用函数、做简单计算，但禁止执行数据库查询、HTTP 请求或复杂业务逻辑 - 变量在
@php块里定义后，可在同一模板后续的{{ }}或其他 Blade 指令中使用（作用域是整个模板） - 不要在
@php里写echo或print，输出统一走{{ }}，否则易混入 HTML 乱序
什么时候该用 @php，什么时候不该用
用 @php 的合理场景极少，仅限于：无法用 Blade 指令简洁表达的临时计算，比如组合多个变量生成一个标识符、做简单类型转换、或调用一个无副作用的辅助函数。
容易踩的坑：
立即学习“PHP免费学习笔记（深入）”；
- 在
@php中调用DB::table(...)->get()→ 违反 MVC 分层，且缓存失效时性能骤降 - 用
@php替代@if/@foreach→ 语法冗余、可读性差、失去 Blade 编译优化 - 在循环里反复 new 对象或解析 JSON → 模板本就不该承担运行时开销
正确做法：把数据处理逻辑提到控制器或 View Composer 中，模板只负责“展示”。
替代 @php 的更安全写法
多数你以为“必须写 PHP”的地方，其实有更清晰、更安全的 Blade 方式：
- 判断变量是否为空且非 0：
@isset($id) && $id !== 0比@php if ($id && $id != 0) { ... } @endphp更直观 - 格式化时间：
{{ $post->created_at->format('Y-m-d') }}，而不是在@php里调用date() - 条件拼接类名：
<div class="btn {{ $disabled ? 'disabled' : '' }}"></div>，无需@php - 需要复用逻辑？写一个
App\View\Components\FormatPrice组件，而不是在模板里写 PHP
Blade 的设计哲学是“模板即声明”，不是“模板即脚本”。越靠近 HTML 结构的逻辑，越要克制写 PHP 的冲动。
缓存和调试要注意的细节
Blade 模板被编译成 PHP 文件并缓存，默认路径是 storage/framework/views/。这意味着：
- 改了
@php里的代码，但页面没变化？先清缓存：php artisan view:clear -
@php块中的语法错误不会立刻报出，而是出现在编译后的 PHP 文件里，错误行号会偏移 —— 查看storage/framework/views/*.php对应文件定位更准 - 开发环境开启
APP_DEBUG=true才能看到完整错误；生产环境它会静默失败或白屏
真正难调试的从来不是语法，而是把本该在控制器里决定的分支逻辑，塞进了模板的 @php 块里 —— 那时候你面对的就不是 PHP 错误，而是业务语义混乱。
