在 web 开发中，html 表单 `` 的命名应兼顾语义清晰、后端可维护性与安全边界，而非简单映射数据库列名；合理命名能提升代码可读性、降低注入风险，并更好支持 laravel 等框架的 mass assignment 机制。
表单字段的 name 属性是数据提交到服务器时的键名，它直接决定后端接收到的请求参数结构。虽然将 name 值设为数据库列名（如 nom、duree、image_emplacement）在 Laravel 中确实能简化 Mass Assignment（例如 $model->fill($request->all())），但这种做法存在明显隐患，不建议作为通用实践。
✅ 推荐命名原则
-
语义优先，非存储映射
name 应反映业务含义，而非底层存储结构。例如： -
使用 snake_case 保持一致性
HTML 表单本身无语法限制，但 snake_case 是 PHP/Laravel 生态的事实标准，利于自动绑定、验证规则定义和调试日志可读性： -
严禁直接暴露主键或敏感字段名
如 name="localisation_id" 虽方便填充，但易被恶意篡改（如越权修改他人记录）。应改用语义化别名，并在控制器中显式映射：// ✅ 安全做法：显式白名单 + 业务逻辑校验 $validated = $request->validate([ 'session_name' => 'required|string|max:100', 'venue_location_id' => 'required|exists:localisations,localisation_id', ]); $session = new Session(); $session->name = $validated['session_name']; $session->localisation_id = $validated['venue_location_id']; // 显式赋值，可控可审计 $session->save(); -
Mass Assignment 不等于“少写代码”，而是“安全地少写”
Laravel 的 fillable 白名单机制（而非禁用 guarded）正是为防止意外覆盖敏感字段（如 is_admin, deleted_at, updated_by）。若为图省事而将所有 DB 列名直接用于 name，等于绕过该防护层：// ❌ 危险：若前端提交 'is_admin=1'，且 'is_admin' 在 fillable 中，则提权成功 protected $fillable = ['nom', 'duree', 'is_admin']; // 不应包含权限字段 // ✅ 正确：仅开放业务必需字段，名称与表单语义一致 protected $fillable = ['session_name', 'session_duration_minutes', 'total_kilometers'];
? 小结：命名不是风格问题，而是架构决策
- name 是前后端契约的第一道接口，应稳定、自解释、可演进；
- 数据库列名属于实现细节，随迁移可能重命名（如 duree → duration_minutes），而表单字段名变更成本更高；
- 使用语义化命名 + 显式映射，反而让代码更易测试、更易国际化（如 session_name 可对应多语言验证提示）、更易做字段级审计。
最终，好的表单命名 = 清晰的业务语言 + 严格的边界控制 + 框架安全特性的充分利用。
