应主动用 select() 明确指定查询字段，而非依赖 select('*') 或默认全查，以避免敏感/大字段泄露、提升性能；关联字段需加表前缀，with() 中的 select() 需单独设置；$hidden/makeHidden 控制序列化输出，不替代查询过滤；DB::table() 无模型隐藏机制，须靠 select() 严格控制；addSelect() 仅用于追加计算字段，不可替代主 select()。
用 select() 明确指定字段，而不是靠 select('*') 或默认查询
Laravel 默认用 get() 会查出所有字段，但实际业务里常有敏感字段（如 password、api_token）或大文本字段（如 content、description）不该返回。靠“排除”思维写代码容易漏、难维护，Laravel 本身也不提供类似 exclude() 的原生方法。
正确做法是：主动列出需要的字段。这既是性能优化（减少网络传输和内存占用），也避免意外暴露数据。
-
select()必须在get()前调用，顺序错了无效 - 别写
select('id', 'name', '*')——*会覆盖前面的字段，且不同数据库行为不一致 - 关联模型的字段要显式加表前缀，比如
users.name、posts.title，否则可能冲突或报错 - 如果用了
with()预加载，select()只影响主模型，不影响关联模型的字段；想控制关联字段，得在闭包里单独写select()
Post::select('id', 'title', 'slug', 'created_at')
->with(['author' => function ($q) {
$q->select('id', 'name', 'avatar');
}])
->get();
用 makeHidden() 或 $hidden 控制序列化输出，不是查询时过滤
很多人想“查询时就去掉 password”，结果在 select() 里漏掉它，却发现 API 返回里还是有 —— 因为 Eloquent 模型从数据库读出来后，只要属性存在（哪怕没查），序列化时仍可能被包含。这时候该用隐藏机制，而非查询过滤。
$hidden 是静态属性，适合全局固定规则；makeHidden() 更灵活，适合单次响应动态控制。
-
$hidden = ['password', 'remember_token']写在模型里，对所有toArray()/toJson()生效 -
$model->makeHidden(['api_token'])只影响当前实例，适合不同接口返回不同字段 - 注意：如果字段根本没查出来（比如没写进
select()），makeHidden()就没意义——它只影响已加载到内存的属性 - 别把
$hidden和数据库权限混为一谈：它不阻止你访问$user->password，只是不输出
警惕 DB::table() 和 Query Builder 的字段歧义
用 DB::table('users') 时没有模型层的 $hidden 机制，全靠 select() 控制字段。但这里更容易踩坑：比如 JOIN 多表时字段名重复，或忘记给字段加别名导致覆盖。
- JOIN 查询必须用
select('users.id as user_id', 'posts.title')这类明确别名，否则id字段可能被覆盖 -
DB::table()->pluck('name')返回的是值数组，不是模型，不存在隐藏逻辑，也无需考虑$hidden - 如果后续要转成模型（比如用
fromQuery()），字段名必须和模型属性完全匹配，否则赋值失败 - 用
DB::raw()时字段名不会自动识别，select(DB::raw('COUNT(*) as total'))中的total必须手动取，不能指望模型映射
复杂查询下，select() 和 addSelect() 的分工要清楚
addSelect() 不是“再选几个字段”，而是为已有查询追加计算字段或子查询字段，常用于统计、分组、条件判断等场景。它和 select() 共存时，顺序和意图必须清晰，否则结果不可控。
-
select('id', 'name')定义主字段集；addSelect(DB::raw('COUNT(comments.id) as comment_count'))是补充字段，需配合leftJoin()和groupBy() - 不能只写
addSelect()不写select()，否则主键等基础字段可能丢失，导致集合无法正常遍历 -
addSelect()的字段不会出现在模型的$casts或$appends中，它是原始查询结果的一部分，类型由数据库返回决定 - 如果用了
distinct，addSelect()的字段必须也在SELECT列表中参与去重，否则 MySQL 8.0+ 会报错
真正麻烦的不是语法怎么写，而是得时刻分清：这个字段要不要进内存？要不要进 JSON？要不要参与后续逻辑？三者目标不同，手段也不同 —— 查不到、取不到、吐不出，得各走各的路。
