MobX中exhaustive-make-observable规则的自动修复行为分析

在MobX的状态管理实践中，makeObservable是一个核心API，它允许开发者显式地标记类成员的可观察性。然而，这个API的使用存在一个常见问题：开发者容易遗漏某些成员的注解，导致意外的非响应式行为。为此，MobX社区开发了eslint-plugin-mobx插件中的exhaustive-make-observable规则来检测这类问题。

规则设计初衷

exhaustive-make-observable规则的主要目的是确保所有类成员都在makeObservable调用中被显式注解。这个设计基于一个重要的前提假设：在大多数情况下，开发者希望所有类成员都是可观察的。如果确实需要排除某些成员，开发者应该明确使用false作为注解。

自动修复的争议

当前规则的自动修复机制将所有未注解的成员默认标记为true（即可观察）。这一行为引发了社区讨论，主要争议点在于：

1. 行为改变风险：自动修复可能无意中改变代码的原有行为，将本应保持非响应式的成员变为可观察
2. 意图不明确：工具无法准确判断开发者遗漏注解的真实意图（是疏忽还是有意为之）

技术实现考量

从技术实现角度看，这个问题涉及几个关键因素：

1. API设计哲学：makeObservable允许部分注解，这是其与makeAutoObservable的主要区别之一
2. 性能考量：完全强制所有成员注解会带来性能开销，这也是API不强制要求完整注解的原因
3. 渐进式采用：对于已有代码库，自动修复可能带来破坏性变更

最佳实践建议

基于讨论，可以得出以下实践建议：

1. 新项目：建议接受默认的true自动修复，这符合大多数新开发场景的预期
2. 已有项目迁移：应使用配置{ "autofixAnnotation": false }来保持原有行为
3. 显式意图：无论采用哪种方式，都应该通过代码审查确保每个成员的注解确实符合业务需求

未来改进方向

社区正在考虑以下改进方案：

1. 可配置的自动修复：允许通过规则配置选择默认注解值
2. 多重修复建议：如果工具支持，可以提供true/false两种修复选项
3. 文档完善：明确说明不同场景下的最佳配置方式

这个讨论体现了工程实践中工具设计与开发者体验之间的平衡考量，也反映了MobX社区对API严谨性和开发者友好性的持续追求。