优先用assign，因其变量挂载到视图引擎实例，全局可用且支持复用；fetch传参仅为本次渲染快照，不透传、易覆盖，适合局部一次性渲染。
ThinkPHP模板赋值用 assign 还是直接传参给 fetch？
直接说结论：优先用 assign，但 fetch 传参只在局部、一次性渲染时更轻量；混用容易导致变量覆盖或遗漏，尤其在控制器继承或中间件介入后。
本质区别不在“能不能”，而在“谁负责生命周期管理”——assign 把变量挂到视图引擎实例上，后续所有 fetch（包括子模板 include）都能访问；而 fetch 的第三个参数是“本次渲染快照”，不持久、不透传。
-
assign是控制器层的变量注册行为，适合复用、组合、条件赋值 -
fetch('index', ['user' => $user])等价于一次性的assign+fetch，但无法被{:include('header')}中的逻辑读取到同名变量 - 若控制器里先
assign('list', $a)，又用fetch('page', ['list' => $b])，页面里$list取的是$b——因为fetch参数会合并覆盖已 assign 的变量（ThinkPHP 6.0+ 默认行为）
为什么 assign 链式调用有时失效？
常见现象：写了 $this->assign('name', 'Tom')->assign('age', 25)，模板里却只显示 $name，$age 是 null。
根本原因不是链式语法错，而是 assign 返回值类型取决于 ThinkPHP 版本和视图驱动配置。TP6 默认返回 $this，但如果你手动替换了视图类、或用了自定义 View 实现，可能返回 null 或新实例。
- 检查是否误写了
$this->view->assign(...)却忘了return $this在自定义方法中 - TP5.1 中
assign返回$this，TP6.0+ 视图对象默认不可链式，需显式写成$this->view->assign(...)->assign(...) - 更稳妥写法是分步：先
$this->assign(...)，再$this->assign(...)，避免依赖返回值
fetch 第三个参数数组里的键名会被自动转成小驼峰吗？
不会。ThinkPHP 模板变量名完全保留传入的键名，大小写敏感，也不做任何转换。
比如 fetch('user/detail', ['user_info' => $data, 'UserId' => 123])，模板里必须用 {$user_info} 和 {$UserId}，不能写成 {$userInfo} 或 {$userid}。
- TP 默认不启用变量名自动标准化，和 Laravel 的
with()不同 - 如果项目统一用小驼峰，建议在控制器里提前处理键名：
array_change_key_case($data, CASE_LOWER)再传入，或封装一个assignCamel方法 - 注意 JSON 数据传进模板后，key 仍保持原样，JS 里取值也要严格匹配
模板里用 {:include('sidebar', ['type' => 'admin'])}，这个 type 能覆盖外层 assign 的同名变量吗？
能，且只在 sidebar 模板作用域内生效。这是 ThinkPHP 视图变量作用域的关键设计点。
外层模板已 assign('type', 'user')，但在 include 里传 ['type' => 'admin']，则 sidebar.html 里 {$type} 是 'admin'，而外层仍是 'user'。
- 这种隔离是通过局部变量栈实现的，不是全局替换，所以安全
- 但要注意：如果
sidebar里又include了其他模板，它传的type不会自动透传，除非显式再传 - 过度依赖嵌套传参会让数据流变隐晦，复杂页面建议统一用
assign预置好上下文，include只传必要差异字段
真正容易被忽略的是变量作用域的“嵌套深度”——assign 是控制器级，fetch 参数是动作级，include 参数是模板级。三层叠加时，哪个值最终生效，得看模板解析时的变量查找顺序，而不是代码书写顺序。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
