That would be a separate proposal - this RFC is strictly scoped to <script setup>.
这将是一个单独的提案--本 RFC 的严格范围是 <script setup> 。.

While I agree about the problem splitting props and emits. I think the DX is greatly improved by this feature. It will reduce the code written by a lot. I'm just scared that people will overuse it.
虽然我同意拆分道具和发射器的问题。我认为这项功能将极大地改进 DX。它将大大减少代码的编写量。我只是担心人们会过度使用它。

Hi Thomas, me too, I'm already using it and it feels already nice. My concerns are definitely about confusion for newcomers, and overuses too.
你好，托马斯，我也是，我已经在用了，感觉已经很不错了。我担心的肯定是新用户的困惑和过度使用。

I would also find it clean enough if it was a utility method such as toModel or something like that where we could give our props and events to it, to keep having a clean separation concern. But it's starting to look like VueUse :).
如果它是一个实用方法，例如 toModel 或类似的方法，我们可以将道具和事件交给它，以保持清洁的分离，我也会觉得它足够简洁。但现在看起来就像 VueUse :).

please no toModel - that really does not appear clean at all to me.
请不要 toModel - 在我看来，这真的一点都不干净。
I probably don'T count as a newcomer anymore, since I started vue a year ago - but to me the approach makes perfect sense as is.
我可能算不上新人了，因为我一年前就开始使用 vue 了，但对我来说，这种方法非常合理。

Imho It is exactly t´he separation from props and events and in tuzrn putting them within their own space which makes this feature good.
我认为，正是由于将道具和活动分开，并将它们置于各自的空间内，才使得这一功能非常出色。
It actually always felt to me like whenever i used 'models' it is semantically something different than props and events and should not have belonged in props and events anyways.
实际上，我总觉得每次使用 "模型 "时，它的语义都与道具和事件不同，无论如何都不应该属于道具和事件。

So are you saying it's just as confusing as props?
你是说它和道具一样令人困惑？

No. I'm saying that reusing a naming convention (define...) which is now used for different purposes (not doable otherwise) could be confusing.
不，我的意思是说，重复使用现在用于不同目的的命名约定（定义......）（否则无法实现）可能会造成混乱。

I don't get what you mean about the name. You want it to sound more like a core thing
我不明白你说的名字是什么意思。你希望它听起来更像一个核心的东西

No. That's actually the opposite : It actually sounds like a core thing introducing a new concept, which is not true and this is why I think it could be more easily adopted if it was named as an utility function.
不，实际上恰恰相反：它听起来像是引入了新概念的核心内容，但事实并非如此，这就是为什么我认为如果将它命名为实用功能，会更容易被采用。

And it's defining a model. toModel makes no sense because it's not converting anything
toModel 没有任何意义，因为它没有转换任何东西。

This. Yes, it's true. I didn't think about it enough to provide something which was perfect, even for me, just to avoid being too verbose in our conversation :).
这个是的，没错。我考虑得不够周全，没有提供一些即使对我来说也很完美的东西，只是为了避免在我们的谈话中过于啰嗦：）。
But actually, provideModel does make sense.
但实际上， provideModel 确实有道理。

I hope that you now get the idea of what I mean. If you don't, it's fine. I'm just trying to give my 2 cents about this new feature, nothing more. I don't really understand why you just thumb down everything I say and answer / ask question as if I was trying to destroy a good idea. I'm actually just sharing thoughts but I feel like you don't really try to understand what I say :). Maybe I'm wrong, and then, I'm sorry. But then, I don't really understand where you are trying to bring me...
我希望你们现在明白我的意思了。如果不明白，也没关系。我只是想谈谈我对这项新功能的看法，仅此而已。我真不明白你们为什么对我说的每一句话都嗤之以鼻，而且回答/提问的方式就好像我在破坏一个好主意一样。实际上，我只是在分享我的想法，但我觉得你们并没有真正去理解我说的话：）。也许我错了，那我很抱歉。但是，我真的不明白你想把我带到哪里去......

But it's for the same purposes? It's just writable defineProps. What you're saying is technically true but also not. It's not a core thing, you don't need to have it, but it behaves like a core thing so that doesn't really matter.
但目的是一样的吗？这只是可写的 defineProps。你说的在技术上是对的，但也是不对的。它不是核心内容，你不需要它，但它的行为类似于核心内容，所以这并不重要。

And I'm just asking questions, is that not allowed?
我只是问问题，这不允许吗？

Also what about being confusing for newcomers? Is it confusing or not, by which I mean more confusing than, for example, props?
另外，新手会不会感到困惑？我指的是比道具等更容易混淆？

I would only think it's confusing for newcomers in the sense that they may not understand what's it's doing under the hood, so debugging problems with models may be difficult at that point, but the same could also be said of using the v-model directive. If you don't fully read the docs, you may not realize that it's a prop and event handler in one, and it works differently based on whether it's used on a native input or on components. But we're all 100% fine with v-model, and this is maybe only abstracting slightly more than v-model but eliminates a good chunk of common boilerplate.
我认为这只会让新手感到困惑，因为他们可能不了解它在引擎盖下做了什么，所以在这一点上调试模型问题可能会很困难，但使用 v-model 指令也会有同样的问题。如果你没有完全阅读文档，你可能不会意识到它是道具和事件处理程序的合二为一，而且它的工作方式也会根据是用于本地输入还是组件而有所不同。不过，我们对 v-model 的使用已经完全没有问题了，而且这可能只是比 v-model 稍微抽象了一些，但却省去了一大块常见的模板。

It's not a core thing, you don't need to have it, but it behaves like a core thing
它不是核心功能，你不需要拥有它，但它的行为就像核心功能一样

That's exactly my point. It's not a core thing, but it presents itself as is. Which could sounds confusing.
这正是我的观点。这不是核心内容，但它却以核心内容的面目出现。这听起来可能令人困惑。

Is it confusing or not, by which I mean more confusing than, for example, props?
我指的是比道具等更让人困惑的东西，到底有没有困惑？

Again, subjectively, I think it's way harder to get (still, for a new dev).
同样，从主观上讲，我认为它更难获得（对新开发人员来说仍然如此）。
Because no : it's not a writeable props system. It's even a worse definition of what it does internally, as props should never be updated by a child. Don't take me wrong, I keep saying the same stuff again and again : that's fine to have such helpers embedded in vue...
因为不：它不是一个可写的道具系统。它的内部定义甚至更糟糕，因为道具永远不应该被子对象更新。别误会我的意思，我一直在重复同样的话：在 vue 中嵌入这样的助手很好...

But one simple exemple of why I think it could be confusing for newcommers : defineModel could allow you to generate a model based on a prop, without having to declare the prop as a model itself. It could make sense to do so, also, I'm not saying you should never do that, but then the concept of what is a model and what isn't could feel blurry if you don't understand that it's a watched ref emitting an event on change.
但有一个简单的例子可以说明为什么我认为这可能会让新用户感到困惑： defineModel 可以让您根据道具生成模型，而无需将道具本身声明为模型。这样做也是有道理的，我并不是说你永远都不应该这么做，但如果你不明白什么是模型，什么不是模型，那么你就会觉得什么是模型，什么不是模型的概念很模糊。

We could argue that it's easy enough for everybody, but again, I think that initial intuition is better than documentation if it can lead to an almost instant understanding just by being named specifically. Here, reading this name, I wouldn't be surprised if at first, someone instinctively thinks about it as a breaking change in the v-model system as it reuses the same naming convention as core features; which in this case, induces a rework of props/emits system with a third completely different approach serving as your defined "writeable props".
我们可以说这对每个人来说都很容易，但我还是认为，如果仅仅通过具体的命名就能让人几乎立即理解，那么最初的直觉比文档更好。在这里，读到这个名称时，如果有人一开始本能地认为这是 v 模型系统中的一个突破性变化，我也不会感到惊讶，因为它重复使用了与核心功能相同的命名约定；在这种情况下，这将导致道具/元素系统的重新设计，并采用第三种完全不同的方法来作为您定义的 "可写道具"。

I would only think it's confusing for newcomers in the sense that they may not understand what's it's doing under the hood
我认为这只会让新手感到困惑，因为他们可能不知道引擎盖下在做什么。

Exactly. 没错。

But we're all 100% fine with v-model, and this is maybe only abstracting slightly more than v-model but eliminates a good chunk of common boilerplate
但我们对 v 模型的使用百分之百没有问题，这可能只是比 v 模型稍微抽象了一点，但却消除了一大块常见的模板

Definitely. That's why I'm saying it's a great feature everybody will eventually use. But I think the naming could be improved to have the same feeling we have using useVModel
当然。这就是为什么我说这是一个人人最终都会使用的伟大功能。但我认为可以改进命名方式，使其与我们使用 useVModel 时的感觉相同。

It behaves like a core thing, so it should have a name like a core thing. defineModel should have always existed, it only behaves like a helper because of the way Vue is architected. If we remade Vue it would be a core thing and probably not be related to emits.
defineModel 本应一直存在，只是由于 Vue 的架构方式，它才表现得像一个辅助工具。如果我们重塑 Vue，它就会成为核心代码，而且可能与 emits 无关。

It really is writable props. You said it isn't, but you only know props as read-only, so for you props = read-only props, so when I say models are writable props, you think models are writable read-only props when I mean just props. Read-only props should be read-only, writable props should be writable. "X should be Y" is never a good argument.
它确实是可写道具。你说它不是，但你只知道道具是只读的，所以对你来说道具 = 只读道具，所以当我说模型是可写道具时，你认为模型是可写的只读道具，而我指的只是道具。只读道具应该是只读的，可写道具应该是可写的。"X 应该是 Y "从来都不是一个好的论点。

I keep hearing this argument that models are somehow unintuitive because it's emitting behind the scenes and for some reason you need to understand that. That's only because defineModel hasn't been here from the start and you're used to it not existing. "A watched ref emitting an event on change" is not simple. Do you know what is? That a model is just a reference to the ref in vmodel. I've only been doing Vue for 8 months, I suppose I could be a newcomer and it's super duper easy. I just looked at a picture comparing defineModel to no defineModel for like 2 seconds and I understood it perfectly. I also have a better explanation here in another reply to someone's comment: #503 (reply in thread)
我一直听到这样的说法：模型在某种程度上是不直观的，因为它是在幕后发射的，出于某种原因，你需要理解这一点。这只是因为定义模型从一开始就不在这里，而你已经习惯了它的不存在。"一个被监视的 ref 在发生变化时发出一个事件 "并不简单。你知道什么是简单吗？模型只是对 vmodel 中 ref 的引用。我做 Vue 才 8 个月，我想我可能是个新手，而且它超级简单。我只看了两秒钟定义模型和不定义模型的对比图片，就完全明白了。我在另一个对某人评论的回复中也有更好的解释：#503 （主题中的回复）

The problem is that you are mixing typing and definition of props. It could be possible to implement something like this:
问题在于，你把类型和道具定义混为一谈了。可以这样实现：

defineProps<{
  prop1?: string,
  modelValue: string
}>({
  models: [ 'modelValue' ]
});

May use better keyword:
可使用更好的关键词：

defineProps<{prop1:string,modelValue:string}>({mutable:['modelValue']})

You can still access them via the modelModifiers prop (currently needs to be declared separately):
您仍然可以通过 modelModifiers 命令访问它们（目前需要单独声明）：

const props = defineProps<{ modelModifiers: { trim?: true } }>()
const msg = defineModel<string>()

if (props.modelModifiers.trim) {
  // ...
}

We can potentially make this automatically handled:
我们有可能实现自动处理：

const msg = defineModel<string, { trim?: true }>()
//    ^ Ref<string | undefined> & { modifiers: { trim?: true }}

if (msg.modifiers.trim) {
  // ...
}

I think we will probably ship current defineModel as stable without this though, because:
不过，我想我们可能会把当前的 defineModel 作为稳定版发布，因为 defineModel 没有这个功能：

1. This is currently not a blocking issue, and seems to be rarely used;
   目前这不是一个阻塞问题，而且似乎很少使用；
2. It can be provided as a follow-up to the current design, and it doesn't seem worth it to cause breaking changes to the current design.
   它可以作为当前设计的后续，而且似乎不值得对当前设计进行破坏性修改。

Follow up on this: we have implemented modifiers support in the latest 3.4.0-rc.3 that doesn't change anything already discussed in this RFC:
跟进：我们已经在最新的 3.4.0-rc.3 中实现了对修饰符的支持，这并没有改变本 RFC 中已经讨论过的任何内容：

const [msg, modifiers] = defineModel<string, 'trim' | 'capitalize'>()

if (modifiers.trim) {
  // ...
}

if (modifiers.capitalize) {
  // ...
}

// type error!
if (modifiers.foo) {}

The returned ref implements Symbol.iterator to support the array destructure.
返回的 ref 实现了 Symbol.iterator 以支持数组的去结构化。

Also implemented get & set transformers so the value conversion can be done without the need for an extra computed wrapper:
还实现了 get 和 set 转换器，因此无需额外的计算包装器即可完成值转换：

const [msg, modifiers] = defineModel<string>({
  set(value) {
    if (modifiers.trim) {
      value = value.trim()
    }
    if (modifiers.capitalize) {
      value = capitalize(value)
    }
    return value
  }
})

@yyx990803 I think it's better to pass the modifiers to the get/set callbacks as second argument:
我认为最好将修改器作为第二个参数传递给 get/set 回调：

const msg = defineModel<string>({
  set(value, modifiers) {
    if (modifiers.trim) {
      value = value.trim()
    }
    if (modifiers.capitalize) {
      value = capitalize(value)
    }
    return value
  }
})

While passing modifiers to get and set looks more encapsulated, avoids captures, and pollutes the global scope less, there are advantages to having them available globally.
虽然向 get 和 set 传递修饰符看起来更加封装、避免捕获并减少对全局作用域的污染，但在全局范围内使用这些修饰符也有好处。

You can change the behavior of your component based on modifiers, or react to the modifiers changing.
您可以根据修改器改变组件的行为，也可以对修改器的变化做出反应。
For example you couldn't create a .debounced modifier inside set().
例如，您无法在 set() 中创建 .debounced 修饰符。.

Maybe having both (globally available + passed to get/set as second parameter) would be a nice compromise.
也许两者兼而有之（全局可用 + 作为第二个参数传递给 get/set）会是一个不错的折中方案。

You could do schema, schemaIndex in schemas and then schemas[schemaIndex]
您可以先写 schema, schemaIndex in schemas 然后再写 schemas[schemaIndex]

See vuejs/core#9598. 请参见 vuejs/core#9598。

When trying to address these issues, I realized the previous behavioral difference between local vs. non-local mode is kinda pointless (and in fact, brings about unnecessary confusion).
在尝试解决这些问题时，我意识到之前本地模式和非本地模式之间的行为差异有点毫无意义（事实上，还会带来不必要的混乱）。

When local is false and the parent doesn't use v-model on the child, the child ref value will always be undefined, making it useless. If the user declared the model with required: true, there would already be a warning about missing modelValue.
当 local 为 false ，且父代没有在子代上使用 v-model 时，子代的引用值将始终为 undefined 。，使其毫无用处。如果用户使用 required: true 声明模型，则会出现关于 modelValue 的警告。就会出现缺少 modelValue 的警告。.

In vuejs/core@f74785b I've removed the local option, making the model automatically adapt based on whether the parent provides v-model or not:
在 vuejs/core@ f74785b 中中删除了 local 选项，使模型能够根据父节点是否提供 v-model 自动调整：

• If the parent provides the necessary v-model prop, the child ref value will always be in sync with parent prop value.
  如果父代提供了必要的 v-model prop，子代的 ref 值将始终与父代的 prop 值保持一致。
• Otherwise, the child ref will behave like a normal local ref.
  否则，子代 ref 的行为将与普通的本地 ref 无异。

After the commit, Problems (1) and (3) are solved. Behavior difference in (2) still exists, but is no longer determined by the local option - instead, it depends on whether the parent provided the v-model props, which I think is reasonable.
提交后，问题（1）和（3）已经解决。第(2)点中的行为差异仍然存在，但不再由 local 选项决定，而是取决于父代是否提供了 v-model 道具，我认为这是合理的。

defineModel('foo', { type: Number })

When you use the component you can't do that with regular v-model directive, instead you need to handle the event and prop yourself:
在使用组件时，您不能使用常规的 v 模型指令，而是需要自己处理事件和道具：

<MyComponent :modelValue="modelValue" @update:modelValue="modelValueHandler">

The modelValueHandler function should look like:
modelValueHandler 函数应该是这样的：

function modelValueHandler(newValue, oldValue) {
    // handle modelValue change
}

Generally speaking, props with an object/array value (default or otherwise) aren't made reactive because you shouldn't be mutating them anyway. Vue won't strip off any existing reactive wrapper, but it won't add one itself either.
一般来说，带有对象/数组值（默认值或其他值）的道具并不是反应式的，因为无论如何你都不应该对它们进行变异。Vue 不会剥离任何现有的反应式封装器，但也不会自己添加一个。

In 3.3, defineModel was implemented using a ref() when local: true was set. You can see that here, vuejs/core@f74785b#diff-ddb3174016350dd4464764b4a1ba232d09ad1e75164d4a37758c759d019202e4L380, where the implementation was changed to a customRef() instead. Unlike ref(), a customRef() won't recursively wrap its properties in a reactive proxy (same as shallowRef() and computed()). This makes it consistent with non-local mode, both with regards to tracking and the automatic unwrapping of refs within that object. So modifying a nested property (effectively what splice does) would have worked in 3.3, but only as an unintended consequence of the use of ref() internally, I think the new behaviour would be considered correct.
在 3.3 中，当设置 local: true 时， defineModel 使用 ref() 实现。您可以在这里看到，vuejs/core@ f74785b #diff-ddb3174016350dd4464764b4a1ba232d09ad1e75164d4a37758c759d019202e4L380，此处改为使用 customRef() 。与 ref() 不同不同的是， customRef() 不会递归地将其属性封装在一个反应式代理中（与 shallowRef() 和 computed() 相同）。这使其与非本地模式保持一致，无论是在跟踪方面，还是在对象内部自动解除反射包装方面。因此，修改嵌套属性（实际上就是 splice 所做的）在 3.3 版中是可行的，但这只是内部使用 ref() 的意外结果，我认为新行为是正确的。

The setter for the customRef does contain a hasChanged check, but it seems to only apply to its implementation of local mode. The emit happens either way. I'm not sure why.
customRef 的设置器确实包含 hasChanged 检查，但似乎只适用于本地模式的实现。无论哪种方式，都会发生发射。我不知道为什么。

Assigning model.value = model.value won't trigger local changes - but it always emits the update:modelValue event.
指定 model.value = model.value 不会触发本地更改，但会始终触发 update:modelValue 事件。

However, the emitted value should still be the same value, so if the parent binds v-model to a ref, it shouldn't trigger any changes either. I'm not sure how @HeuHax's use case looks like.
不过，发射的值仍应是相同的值，因此如果父级将 v-model 绑定到 ref，也不会触发任何更改。我不确定 "用例 "是怎样的。

<script setup>
const model = defineModel({ type: Array, default: [] })
</script>

<template>
  <div>Not updating: {{ model.join(',') }}</div>
  <button @click="model.shift();">-1</button>
  <button @click="model.push(model.length);">+1</button>
</template>

it like this? SFC Playground
像这样吗？SFC 游乐场

the same playground as @nined9 with a reactive array (default() { return reactive([]) }) works:
和使用反应数组 ( default() { return reactive([]) } ) 一样：
Modified SFC Playground 改建的 SFC 游乐场

@jods4 default() { return reactive([]) } works amazing! Thank you so much!
default() { return reactive([]) } 效果惊人！非常感谢
I feel a bit dumb for not trying the default as a reactive([]).
我觉得自己有点笨，没有尝试将默认设置作为反应式（[]）。

This is the wrong place to discuss issues. Please open a separate issue.
在这里讨论问题是错误的。请另开一个问题。