在循环内调用computed signal是否属于不良编程实践？

核心结论 #

这并非必须从原则上避免的不良实践，但第二种写法（提前缓存signal值）在可读性、可维护性上更优，性能层面的差异在绝大多数场景下可以忽略。

两种写法的差异分析 #

先明确两种实现的核心区别：

1. 第一种写法：在filter的每一次迭代中调用searchString()

const filtered = computed(() => {
  return listItems.filter(item => item.name.includes(searchString()));
});

2. 第二种写法：提前缓存searchString()的结果，再在循环中复用

const filtered = computed(() => {
  const search = searchString();
  return listItems.filter(item => item.name.includes(search));
});

性能角度

Angular的signal（包括computed signal）有两层缓存机制：

• 普通signal的getter只是读取当前值，开销极低；
• computed signal会缓存计算结果，只有当依赖的signal值变更时才会重新计算。

你的测试结果（10000次调用耗时5ms）也验证了这一点：重复调用computed signal时，只要依赖未变，就直接返回缓存结果，不会触发重复计算。

即使是第一种写法，在filtered的单次计算过程中，多次调用searchString()（每次filter迭代一次），由于searchString的缓存机制，实际也只会获取一次最新值（如果是computed signal）或直接读取内存值（如果是普通signal），性能开销几乎可以忽略。只有当listItems规模极大（比如十万级以上）时，才可能出现微小的性能差异，但这种场景在前端业务中并不常见。

代码质量角度

第二种写法更具可读性：它明确地将依赖值提取出来，让代码阅读者一眼就能知道——search的值在整个computed计算过程中是固定的，不会在循环迭代中意外变更。而第一种写法可能会让维护者产生疑问：“每次迭代调用searchString()会不会拿到不同的值？”（虽然实际不会，但增加了认知成本）。

从这个角度看，第一种写法算不上“代码异味”，但第二种写法更符合清晰、简洁的代码风格。

总结建议 #

• 若追求极致的代码可读性和可维护性：优先选择第二种写法，提前缓存signal值；
• 若项目中已有类似第一种写法的实现：无需强制修改，因为它不会带来明显的性能问题；
• 特殊场景：如果searchString是一个包含复杂计算逻辑的computed signal，即使有缓存，提前提取变量依然能让代码逻辑更清晰，避免让阅读者误解循环内存在重复计算。

内容的提问来源于Stack Exchange，提问作者Stephen Paul