ThinkPHP模型字段默认值需手动实现多层fallback，应在setXxxAttr()中按请求上下文→配置→环境变量→硬编码顺序判断，避免在$default中使用未初始化的config()闭包。
模型字段默认值从数据库、配置、代码三处动态 fallback 怎么写
ThinkPHP 的模型字段默认值不是静态写死的，而是支持多层 fallback：数据库表结构定义 > 模型属性 $default > 构造时传参 > save() 时显式赋值。但很多人卡在「想让某个字段优先取配置项，没配再取环境变量，最后才用硬编码默认值」——这得手动干预，框架不自动帮你串起来。
实操上，最稳的方式是在模型的 initialize() 或字段的 setXxxAttr() 里做判断，而不是依赖 $default 数组——因为 $default 只认固定值或闭包，没法感知运行时上下文（比如当前请求的用户角色、APP_ENV 环境）。
- 别把逻辑塞进
$default['status'] = function() { return config('default_status') ?: 'draft'; };——闭包在模型类加载时就执行了，config 还没初始化，会返回 null - 真正生效的做法是重写
setCreateTimeAttr()，在里面按需查配置、读环境变量、调服务类 - 如果字段要参与
create()或save()的自动填充，必须确保该字段没被设为readonly，且不在$updateTime/$createTime自动管理名单里，否则会被覆盖
为什么 $default 里的闭包经常取不到 config 或 request？
ThinkPHP 加载模型类时，$default 数组是类定义的一部分，会在容器初始化前就被解析。此时 config() 函数还没注册，request 实例也不存在。所以闭包看似写了，实际执行时机错位，结果永远是 null 或报错 Call to a function undefined: config()。
- 错误写法：
$default = ['status' => function() { return config('order.default_status'); }]; - 正确写法：在
setOrderStatusAttr($value)中判断if (is_null($value)) { $value = config('order.default_status', 'pending'); } - 注意：这个方法只对
save()和create()生效；直接 new 模型再赋值不会触发 setXxxAttr，得手动调用
不同场景下 fallback 顺序怎么控制才不冲突
fallback 不是越深越好，关键看字段语义。比如 tenant_id 应该优先取当前登录租户（来自中间件注入），其次才是配置兜底；而 version 字段可能要先查数据库最大值 +1，失败再用时间戳。顺序错了，数据就错。
立即学习“PHP免费学习笔记（深入）”；
- 数据库值 > 当前请求上下文（如
session('tenant_id')） > 配置项（config('app.tenant_fallback')） > 硬编码（'default_tenant'） - 避免在多个地方重复写 fallback 逻辑：统一收口到
setTenantIdAttr()，不要又在控制器里判断又在模型里判断 - 特别注意软删除字段
delete_time：如果它也在$default里设了值，和softDelete()的行为会打架，导致删除失败或数据不一致
性能和兼容性要注意的三个细节
动态 fallback 看似灵活，但每多一层判断就多一次函数调用或 IO。尤其在批量插入（saveAll()）时，如果每个模型实例都去查 config 或 session，开销会明显上升。
- config 值尽量用
Env::get()替代config()，前者是纯数组访问，后者带合并逻辑 - session 数据如果只是租户 ID 这种轻量字段，建议中间件里提前塞进 Request 对象的 param，然后在
setXxxAttr()里用input('tenant_id')取，比session()快 - ThinkPHP 6.0+ 的模型事件（
onBeforeInsert）也能做 fallback，但要注意：事件回调无法修改原始数据对象，只能改$data参数，且不适用于单个字段的细粒度控制
真正难的不是写几行 fallback 代码，而是想清楚「这个字段的默认值，到底由谁负责决策」——是数据库约束？是业务策略？还是部署环境？搞混责任边界，后面加个新环境变量就得全量改模型。
