使用JSON.stringify、正则、JSON.parse操作JS对象是否属于不良开发实践？

你的判断完全正确，这种通过JSON.stringify+字符串替换+JSON.parse修改对象的写法，除非是经过全量边界验证的极端特殊场景，否则都属于不可接受的不良生产代码实践。

这种写法的核心风险 #

• 极易产生隐蔽的逻辑错误：字符串替换没有上下文感知能力，只要对象中其他位置（比如其他属性的键名、字符串类型的属性值）刚好出现了你要匹配的字符，就会出现误改。比如你要把键名uid替换成userId，如果某个属性值是"uid12345"，替换后值也会被改成"userId12345"，这类错误非常隐蔽，很难在常规测试中被发现。
• 序列化阶段就会丢失数据：JSON.stringify本身有非常多的序列化限制：会自动丢弃undefined、Symbol、函数、循环引用内容，Date对象会被转成普通字符串，Map、Set、正则等特殊对象会被序列化为空对象，经过这一步处理后，反序列化得到的对象已经和原始对象的结构、类型完全不一致。
• 性能开销极高：序列化、全局字符串替换、反序列化三步操作的复杂度都远高于直接操作对象属性，当处理大型对象、或者这段逻辑被高频调用时，会产生完全不必要的性能浪费。
• 可维护性极差：其他开发者很难快速通过这段代码理解修改目标，后续对象结构迭代时，字符串匹配规则需要同步调整，甚至可能要完全重写这段逻辑，维护成本是直接操作对象的数倍。
• 容易触发全局异常：如果字符串替换不小心破坏了JSON格式（比如误删了引号、大括号），后续JSON.parse会直接抛出异常导致程序崩溃，排查这类问题需要全链路校验序列化、替换、反序列化的所有输出，排查成本极高。

给新同事的解释思路 #

可以先肯定他快速解决问题的思路，再同步上面的风险，最后给出对应的更优方案示例，比如：

1. 如果是修改单层对象的键/值：

// 不推荐的写法
const newObj = JSON.parse(JSON.stringify(oldObj).replace('oldKey', 'newKey'))

// 等价的更安全写法
const { oldKey, ...rest } = oldObj
const newObj = { ...rest, newKey: oldKey }

2. 如果是修改多层/批量对象属性，可以写递归遍历函数处理属性，不需要经过序列化步骤。
3. 如果他本来是想顺便做深拷贝，可以推荐用原生structuredClone方法或者项目内的深拷贝工具函数，比JSON序列化的兼容性和可靠性高很多。

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