新增和编辑应共用控制器方法但需差异化处理：请求参数、验证规则、数据写入方式三处必须区分，如编辑时忽略password、动态添加unique ignore、按exists判断关联操作，避免前端传参不一致导致静默异常。
不需要硬性分开，但必须区分处理逻辑——新增和编辑共用一个控制器方法是常见且合理的，关键在于请求参数、验证规则、数据写入方式这三处必须差异化处理。
为什么不能直接复用 store() 和 update() 的默认逻辑
默认的 store() 和 update() 方法看似对称，但实际场景中它们面对的数据来源、校验约束、关联处理往往不同：
- 新增时可能要求必填字段（如
password），编辑时这些字段应被忽略或设为可选 - 编辑时需校验唯一性是否被自己当前记录占用（比如改邮箱，得排除本用户ID）
- 某些字段只允许新增时设置（如
created_by），编辑时禁止更新 - 关联关系处理不同：新增可能要同步创建子记录，编辑则需比对差异后增删改
Laravel 中最稳妥的写法：统一入口 + 条件分支
把新增和编辑都路由到同一个控制器方法（比如 upsert() 或复用 store()），靠请求中是否存在 id 或是否为 PUT/PATCH 请求来判断上下文：
- 用
$request->route()->getName()或$request->isMethod('PUT')区分动作意图 - 验证规则动态生成：
Rule::unique('users')->ignore($id)在编辑时才加ignore() - 数据填充前做条件过滤：
Arr::except($data, ['password'])仅在编辑时执行 - 模型事件或观察者里也可通过
$model->exists判断是 insert 还是 update
容易踩的坑：前端传参不一致导致逻辑错乱
最常出问题的是前端没区分「新增表单」和「编辑表单」的字段结构，比如：
- 新增页没传
id字段，编辑页却漏传了_method=PUT，结果走进store()导致主键冲突或默认值覆盖 - 复选框字段（如
roles[]）在新增时为空数组，编辑时未回显已选项，导致提交后清空关联 - 时间字段（如
published_at）新增时自动设为 now()，编辑时却被表单默认值覆盖成空字符串，入库变0000-00-00 00:00:00
这类问题不会报错，但数据状态会静默异常——必须在控制器里对关键字段做存在性校验和类型归一化，而不是依赖前端传什么就存什么。
真正难的不是拆不拆方法，而是每个字段在不同上下文中的语义是否被明确识别和保护。哪怕写在一个方法里，也要像给每行代码加注释一样，清楚地标出「此处仅适用于新增」「此处仅在编辑时生效」。
