本文详解为何在保存 `submission` 模型时，mongoose 错误地触发了 `form` 模型的字段验证（如 `title`、`description` 必填），并给出根本原因与正确解决方案。
你遇到的错误信息非常具有迷惑性：
Form validation failed: inputField: Path `inputField` is required., description: Path `description` is required., title: Path `title` is required.⚠️ 关键点：这个错误并非来自 Submission 模型本身的验证失败，而是 Mongoose 在保存 Submission 实例时，意外尝试对关联的 Form 文档执行了 .validate() 或 .save() 操作——这通常只会在你无意中将 form 字段赋值为一个已加载的 Form 文档实例（而非 ObjectId）时发生。
回顾你的代码：
const submissionItem = new Submission({ "form": form._id.toString(), // ❌ 问题不在此（转字符串本身无害） "user": user._id.toString() })表面看只是传入了 ID 字符串，但结合错误栈和常见陷阱，真正的问题极可能出在：你在其他地方（比如中间件、pre-save hook、或某次调试修改中）给 Submission Schema 添加了 ref 关联的级联验证逻辑，或者更常见的是——你误将 form 字段设为了 Form 模型实例本身，而非其 _id。
但注意：你提供的 submission.model.js 中 form 字段定义是标准的 ObjectId 引用：
form: { type: Schema.Types.ObjectId, ref: 'Form' }✅ 这本身不会触发 Form 的验证。Mongoose 只有在你显式调用 form.save()、form.validate()，或使用 populate() 后修改再保存，或在 pre(‘save’) 中对 this.form 执行操作时，才会校验 Form 模型。
? 那么为什么报错指向 Form 的 title 等字段？
→ 唯一合理解释是：你在创建 submissionItem 时，实际传入的 form 值是一个完整的 Form 文档对象（即 form 变量本身），而不是 form._id。
你日志中打印的 ========form { … title: ‘Peng’, description: ‘dfdfd’, … } 正是铁证——说明 form 是已查出的 Model 实例。
而当你写：
const submissionItem = new Submission({ form: form, user: user._id })（即使没写出来，但调试中可能临时改过），Mongoose 会尝试将整个 Form 实例赋给 form 字段。由于类型不匹配（期望 ObjectId，得到 Object），Mongoose 可能静默转换失败，或在后续 save 流程中触发深层校验逻辑，最终抛出 Form 自身的验证错误。
✅ 正确做法（也是答案所强调的核心）：始终确保传入的是纯净的 _id（ObjectId 或字符串），且不要额外调用 form.save() 或 form.validate()。
以下是修复后的完整、健壮的服务代码：
const createSubmission = async (formID, requestingUsername) => { try { // ✅ 严格校验输入 if (!formID || !requestingUsername) { throw new Error('formID and requestingUsername are required'); } const user = await User.findOne({ username: requestingUsername }); if (!user) throw new Error(`User ${requestingUsername} not found`); const form = await Form.findById(formID); if (!form) throw new Error(`Form ${formID} not found`); // ✅ 关键：只传 form._id 和 user._id（原生 ObjectId，无需 .toString()） const submissionItem = new Submission({ form: form._id, // ← 直接传 ObjectId，类型安全 user: user._id // ← 同理 }); // ✅ 保存前可选：显式验证（非必需，save 会自动做） await submissionItem.validate(); await submissionItem.save(); console.log('✅ Submission saved successfully:', submissionItem._id); return true; } catch (err) { console.error('❌ Submission save failed:', err.message); // 可选择抛出错误供上层处理，而非仅返回 false throw err; } };? 额外注意事项：
- 避免 .toString()：form._id.toString() 生成字符串，虽能被 Mongoose 转回 ObjectId，但多此一举且可能在某些版本引发隐式转换问题。直接传 form._id（ObjectId 实例）最稳妥。
- 检查 Schema 中是否有 required: true 误配：确认 Submission Schema 中 form 和 user 字段没有错误地设置 required: true（它们作为引用，通常应允许为空或由业务逻辑保证存在，而非靠 schema 强制）。
- 排查 pre-save hooks：检查 SubmissionSchema.pre(‘save’, …) 或 FormSchema.pre(‘save’, …) 中是否意外操作了关联数据。
- 启用 Mongoose debug 日志：在连接数据库前添加 mongoose.set(‘debug’, true)，可清晰看到每条执行的 mongodb 命令，帮助定位是否有多余的 Form save 操作。
总结：该错误本质是数据类型误用 + 验证上下文混淆。牢记 —— 引用字段只存 ID，不存文档；验证只作用于当前模型实例。遵循这一原则，即可彻底规避此类“跨模型验证误报”问题。