嘿，这个问题问到点子上了——不少刚上手React表单的开发者都会下意识这么做，结果踩了一堆莫名其妙的坑。咱们从React的核心设计逻辑和实际开发痛点来拆解：

1. 最直接的问题：数据同步失效，出现“幽灵状态” #

假设你写了一个表单组件，父组件传了个userName作为props，你在子组件里用const [name, setName] = useState(props.userName)把它转成state。一开始看起来没问题，但如果父组件里的userName更新了（比如用户切换了编辑对象），子组件的name state并不会自动跟着变！

你想想这个场景：用户先编辑“张三”的信息，然后切换到编辑“李四”，结果表单里还显示着“张三”，用户改完提交，直接把李四的信息改成了张三的修改版——这bug够头疼吧？本质就是子组件的state和父组件的props脱节了，形成了不受控的“幽灵状态”。

2. 违背React的单一数据源原则 #

React的核心优势之一就是单向数据流+单一数据源，这样数据流向清晰，调试起来一目了然。如果把props转成state，等于在组件里搞出了两个数据源：父组件的props和子组件的state。你得手动写useEffect去监听props变化同步state，不仅增加了代码复杂度，还很容易漏写或者写错依赖项，埋下隐患。

比如你加了useEffect(() => setName(props.userName), [props.userName])，看起来解决了同步问题，但这时候子组件的state其实完全是props的镜像，那为啥不直接用props+回调函数来处理呢？多此一举嘛。

3. 状态冗余，增加维护成本 #

本来可以直接基于props做渲染和交互的逻辑，非要把值存成state，平白多了一层状态管理。后续维护的时候，其他开发者看到这个组件，得花时间搞清楚：这个state是和props同步的？还是完全独立的？如果同步的话，有没有同步逻辑？无形之中增加了理解成本，也容易因为误解写出bug。

那有没有例外情况？ #

也不是绝对不能用——如果这个props只是作为一次性初始值，后续完全由子组件自己控制，父组件再也不会更新这个props，那是可以的。比如一个新建用户的表单，父组件传了默认的“未命名”作为初始值，之后用户输入的内容完全由子组件管理，父组件不干涉。这时候建议把props命名成initialUserName而不是userName，明确告诉其他开发者：这只是初始值，后续和父组件无关。

总结下来，核心就是：React表单里尽量保持数据流向的清晰，要么用受控组件（完全依赖props+父组件回调），要么用非受控组件（用ref或者本地state，但明确初始值的作用），别搞props转state这种两头不靠的操作，不然坑等着你跳。

内容的提问来源于stack exchange，提问作者jeremyTob