结构化传参优于多参数拼接，推荐用对象封装业务数据并区分业务数据与交互上下文；结合 defineEmits 类型校验，避免传响应式引用或大对象。
在子组件中用 emit 传复杂业务参数，关键不是“能不能传”，而是“怎么传得清楚、接得稳、改得少”。核心原则是：结构化优先、语义明确、边界清晰。
用对象封装业务数据，而不是拼一堆参数
当参数涉及用户信息、表单状态、操作上下文等多字段组合时，直接 emit('submit', id, name, email, isValid, timestamp) 很容易错序、漏参、难维护。推荐统一打包成对象：
- 子组件内：
this.$emit('form-submit', { userId: 1024, formData: { name: '张三', phone: '138...' }, action: 'create', source: 'modal' }) - 父组件接收函数只需一个形参：
handleSubmit(payload) { console.log(payload.action, payload.formData.name) } - 好处明显：字段名自解释、增减字段不影响调用签名、TypeScript 可精准推导类型、后续加日志或埋点也方便扩展
区分“业务数据”和“交互上下文”，避免混传
有些场景需要同时知道“子组件发了什么”和“父组件当前在哪条数据上触发的”。比如列表中每个卡片都有编辑按钮，父组件需知道“编辑的是第几项”以及“新内容是什么”：
- 子组件只传业务数据：
this.$emit('update-item', { title: '新标题', status: 'draft' }) - 父组件模板中显式补上下文：
<item-card v-for="(item, i) in list" :key="item.id" @update-item="onUpdateItem($event, i)"></item-card> - 父组件方法：
onUpdateItem(data, index) { this.list[index] = { ...this.list[index], ...data } } - 这样分离后，子组件完全不感知索引逻辑，复用性更高
结合 defineEmits 做运行时校验（Vue 3 推荐）
如果业务参数结构固定，可在子组件中提前声明并校验，避免传错类型导致父组件静默失败：
const emits = defineEmits({ 'user-action': (payload) => { return typeof payload === 'object' && 'id' in payload && 'type' in payload } })- 或者更严谨地配合 TypeScript 接口：
defineEmits<{ (e: 'save', data: UserForm): void }>() - 开发阶段就能捕获
emits('save', 'abc')这类类型错误，比 runtime 报错更早发现问题
避免在 emit 中传大对象或 DOM 引用
业务参数要“轻量可序列化”，别传 ref、computed、el 或深层嵌套的响应式对象：
- ❌ 错误示例：
this.$emit('notify', this.formRef)—— 父组件无法安全使用，还可能引发响应式污染 - ✅ 正确做法：提取必要字段，如
{ id: this.id, values: { ...toRaw(this.formData) } } - 尤其注意：v-model 的
modelValue应只传原始值（字符串、数字、布尔），不要传对象除非明确约定
