_db、model、view 不是同层级工具：_db 是 tp3.x 的已废弃函数，tp6 中完全不存在；model 是模型实例化助手，不自动查询；view 是视图渲染助手，支持变量传递与链式赋值。
直接说结论： _db、model、view 三个不是同层级的工具，不能并列比较；_db 是已废弃的旧版函数（TP5.0 之前），model 是模型类实例化助手（TP5+），view 是视图渲染助手（TP5/6 兼容）——混用会导致调用失败或行为不可控。
为什么 _db() 在 ThinkPHP6 中根本不能用
_db 是 ThinkPHP3.x 时代的全局函数，底层直接 new Db 类并返回单例。TP5.0 起彻底移除该函数，TP6.0 中连函数定义都不存在。如果你在 TP6 项目里写 _db('user')->select()，会直接报 Fatal error: Uncaught Error: Call to undefined function _db()。
- 替代方案只有
\think\facade\Db::table('user')->select()或注入Db门面 - 若项目从 TP3 升级而来，必须全局搜索替换
_db(→Db::table( - 注意：TP5.1+ 的
db()（小写）是存在的，但它是数据库连接管理器，不等价于旧_db，也不能链式调用 query/select
model() 助手函数只负责“新建模型实例”，不执行查询
model('User') 等价于 new \app\model\User()（自动解析命名空间），但它只是个空对象，没触发任何数据库操作。常见误解是以为它能直接查数据，比如 model('User')->find(1) 看似可行，实则依赖模型类是否定义了 find 静态方法 —— 而 TP6 默认模型不继承 think\Model 时，find 根本不存在。
- 正确用法：确保
app\model\User继承\think\Model，否则model('User')返回的对象无法调用select/find - 性能提示：每次调用
model()都会 new 一次实例，高频场景建议复用变量或改用依赖注入 - TP6 推荐写法其实是
app\model\User::find(1)，语义更明确，也避免了助手函数的隐式解析开销
view() 渲染视图时，变量传递方式决定作用域边界
view('index', ['name' => 'thinkphp']) 这种写法在 TP5/6 都可用，但底层机制不同：TP5 中它等价于先 View::assign() 再 View::fetch()；TP6 中则通过 think\facade\View 门面统一调度，支持延迟赋值和模板继承。
- 传参数组里的键名会变成模板中可直接使用的变量，如
{$name}；但嵌套数组需展开，['user' => ['id'=>1]]后模板里不能写{$user.id}，得用{$user['id']} - 如果同时用了
$this->assign()和view()传参，后者会覆盖前者同名变量（TP6 默认行为） - TP6 中更推荐控制器里用
return view('index')->assign('name', 'tp6')链式写法，避免数组传参带来的 key 冲突风险
真正容易被忽略的是：这三个函数的加载时机完全不同。model() 和 view() 是运行时动态解析类名，一旦命名空间写错或模型类文件缺失，错误直到执行那一刻才暴露；而 _db 是纯粹的符号不存在问题，报错最干脆。选哪个，本质是在选“抽象层级”——别为了少敲几个字符，把调试成本翻倍。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
