Solid中以无操作表达式指定createEffect依赖是否存在问题？

1. 依赖追踪极度脆弱 #

你在effect里通过空读取props.dynamicFeatures来触发依赖追踪，这种写法完全依赖“代码里存在这个读取操作”维持效果。如果后续有人重构时不小心删掉这行、或者把它移到节流函数内部（而节流函数的执行被延迟/跳过），Solid就会失去对这个依赖的追踪，effect再也不会在props.dynamicFeatures变化时触发，直接导致功能失效。

而on()的写法是显式声明依赖源，依赖关系被固化在API层面，不会因为代码的小改动意外断裂。

2. 语义模糊，可读性差 #

空读取props.dynamicFeatures的行为没有任何业务逻辑意义，其他开发者看到这段代码时会完全困惑——为什么要写一行既不赋值也不参与计算的代码？这种“隐式依赖”的写法相当于给代码埋了一个需要额外解释的坑，维护成本极高。

相比之下，on(() => props.dynamicFeatures, updateDynamicMapLayers)的写法一目了然，直接表达了“当props.dynamicFeatures变化时执行updateDynamicMapLayers”的意图，可读性和可维护性拉满。

3. 节流函数放大依赖隐患 #

你的updateDynamicMapLayers是节流函数，本身会延迟或合并执行。如果后续需要在这个节流函数内部添加其他响应式依赖，第一种写法里的effect根本不会追踪这些新依赖——因为effect的依赖范围只限于外层的props.dynamicFeatures读取。而on()的写法至少依赖源明确，后续调整依赖时更容易修正。

4. 不符合Solid设计范式 #

Solid鼓励开发者显式管理响应式依赖，on()就是专门用来处理“依赖变化触发回调”场景的API。第一种写法属于利用依赖追踪的“漏洞”实现需求，虽然暂时能运行，但不符合框架的设计意图，后续框架版本更新时（比如依赖追踪逻辑优化），这种写法可能出现兼容性问题。

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