推荐优先修改 Vue 的插值定界符（如设为 [['${', '}']]），避免改动 ThinkPHP 深度耦合的 {} 语法；literal 标签仅作用于模板编译期，无法解决运行时 Vue 渲染冲突；最佳实践是 TP 仅提供挂载点与初始数据，其余交由 Vue 全权控制。
Vue 模板语法和 ThinkPHP 的 {} 冲突怎么办
ThinkPHP 默认用 {} 包裹模板变量（如 {$name}），而 Vue 也默认用 {{}} 写响应式插值，直接混用会导致 PHP 解析失败或 Vue 渲染异常——比如页面显示空白、报错 Parse error: syntax error，或者 Vue 表达式被 TP 当作变量提前替换了。
最直接的解法是让两者“错开”：要么改 Vue 的定界符，要么改 ThinkPHP 的模板定界符。推荐优先改 Vue 的，因为 ThinkPHP 的 {} 在布局、包含、条件判断等场景深度耦合，动它容易引发连锁解析问题。
- 在 Vue 实例或全局配置中修改
delimiters，例如用['${', '}']或['[[', ']]'] - 确保在引入 Vue 之后、创建实例之前设置，否则已编译的模板不会生效
- 如果用 Vue CLI 或构建工具，需在
main.js或入口 Vue 配置里设；若直接 script 引入，写在new Vue({})前即可
ThinkPHP 的 literal 标签真能兜住所有 Vue 代码吗
literal 标签确实能阻止 ThinkPHP 解析其中内容，常被用来包裹整段 Vue 模板，但它不是万能保险。它只对标签内「静态文本」生效，一旦里面出现 ThinkPHP 的动态语法（比如 {:date('Y-m-d')} 或 <include file="xxx"></include>），TP 仍会尝试解析，导致错误或意料外的输出。
更隐蔽的问题是嵌套：如果 Vue 组件里用了 v-for 渲染含 {} 的字符串（比如日志内容），而你又没关掉 Vue 的 HTML 转义，literal 完全不介入运行时渲染阶段，这时候冲突照旧发生。
立即学习“PHP免费学习笔记（深入）”；
-
literal只作用于模板编译期，对 Vue 运行时生成的内容无效 - 不要在
literal内混写 ThinkPHP 语法，哪怕看起来“没被解析”——可能只是恰好没报错，但行为不可控 - 若必须共存动态内容，优先用 Vue 的
v-html或计算属性拼接，而非依赖 TP 输出原始 HTML
改 ThinkPHP 定界符的风险和实操边界
虽然 ThinkPHP 支持通过配置 template.tpl_begin 和 template.tpl_end 修改定界符（比如改成 [% %]），但这会影响所有模板文件、内置标签、第三方扩展包的兼容性。很多 TP 插件、Admin 模板、甚至官方 think-view 的底层逻辑都硬编码了 {}，改了之后常见现象是 include 失效、volist 不渲染、甚至路由解析出错。
只有在全新项目、无历史模板、且团队明确约定不用任何 TP 模板语法（纯 Vue + API）时，才建议动这个配置。否则不如接受“TP 负责结构骨架，Vue 负责局部交互”的分工。
- 修改位置在
config/template.php中，键名为tpl_begin和tpl_end - 改完后需清空
runtime/view/缓存，否则旧缓存仍按原定界符编译 - 所有已有模板里的
{$var}、{if}等必须批量替换，IDE 查找替换时注意别漏掉注释或字符串里的假匹配
Vue 单文件组件（SFC）和 ThinkPHP 混用的现实路径
真正长期可维护的做法，是让 Vue 走标准构建流程（Webpack/Vite），ThinkPHP 只做纯 API 后端。但若受限于老项目无法拆分，只能在 TP 模板里嵌入 Vue，那必须接受一个事实：你不是在“集成 Vue”，而是在“给 Vue 让出一段不被 TP 碰的 HTML 区域”。这时关键不是语法怎么躲，而是边界怎么划清楚。
- TP 模板里只留一个挂载点，如
<div id="app"></div>，其余全部由 Vue 控制 - 避免在 TP 模板中写任何
{{}}、v-指令，哪怕只是调试用的{{debug}} - 如果要用 TP 变量初始化 Vue 数据，用
data-属性传入，再在 JS 里读取：<div id="app" data-user="<{:json_encode($user)}>"></div>
最麻烦的永远不是语法冲突本身，而是团队成员随手在 TP 模板里加个 {$xxx}，又在旁边写个 {{yyy}}——没人记得谁该负责哪一段。边界一旦模糊，改起来比重写还累。
