为何fetch(API_URL)与fetch(url)两种写法均能正常工作？

这两种写法都是完全合法的实现，只是数据筛选的阶段不同，只要对应的后端接口支持，自然都能正常工作：

• 你的实现：先通过fetch(API_URL)拉取全部文章的数组数据到前端，再用Array.prototype.find()在浏览器端筛选出对应ID的文章。这种方式能跑通的前提是，你调用的API_URL接口本身就会返回完整的文章列表。
• 讲师的实现：通过拼接URL（比如/api/posts/${postId}），让后端直接返回指定ID的单篇文章。这种方式依赖后端提供了「根据ID获取单篇内容」的接口，是RESTful接口设计里的常见模式。

两者的核心差异 #

• 性能与带宽：如果文章数量多，你的写法会一次性拉取所有数据，浪费带宽且首次加载慢；讲师的写法只请求需要的单篇数据，更高效。
• 使用场景：如果后续需要频繁切换查看不同文章，你的写法可以把全量数据缓存起来，避免多次发请求；如果只需要查看单篇内容，讲师的写法更合理。
• 接口依赖：你的代码依赖返回全量列表的接口，而讲师的代码依赖单篇查询接口。

简单说，不存在谁对谁错，只是两种不同的数据流设计，只要后端接口匹配你的调用方式，代码就能正常运行。

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