[esnext] “所有import语句写在模块开始处”的说明是错误的

[hax]

“import会被默认提升至模块最前面”这个说法是错误的，实际并不会。

“浏览器如能尽早读取相关的import内容则有可能更早地请求相关的依赖模块，有一定的性能提升作用，在HTTP/2之后可能会具有更明显的效果。”——这些说法也存疑，虽然理论上似乎是可能的。实际上更可能的是服务器端利用HTTP/2在没有请求的情况下预先发出被依赖的module——然而此种优化与import的前后并无关系。

另外bad的代码本身是错误的，import语句只能在top-level，而不能在函数里。

[otakustay]

那么 @hax 本身赞成import均写在文件最前这个方式吗

[hax]

@otakustay

我个人试验过就近import的写法（写在第一个需要此导入的函数之前，例子 https://github.com/baixing/jedi/blob/master/src/transform/import.js ），其实也还行，主要的问题在于 import 是不能重复的，意味着你其实无法就近写出所有的依赖。此外因为只能在top-level所以在函数体比较大的情况下也不能做到真正的就近（反而是commonjs的require可以真正就近）。

我的感觉是：如果模块足够小和内聚，当然全写在模块顶部是很ok的。
问题可能出在比较复杂的模块，比如api入口文件（facade模式）。这时就近import有助于在阅读单一功能时更快看清楚依赖。然而这也许是模块需要进一步拆分的信号。

总的来说，我略微倾向于全写在最前面。

[Phinome]

印象中 C , JAVA 都是在文件 top import 吧

[otakustay]

是的，我理解它们将import作为一个源码的meta信息看待

在 2015年11月12日，下午1:22，Phinome notifications@github.com 写道：

印象中 C , JAVA 都是在文件 top import 吧

—
Reply to this email directly or view it on GitHub.

[errorrik]

那 @otakustay 改改说明？

[errorrik]

根据 @hax 阐述的

因为只能在top-level所以在函数体比较大的情况下也不能做到真正的就近（反而是commonjs的require可以真正就近）。

以及与 @otakustay 的讨论，既然做不到就近，其他语言都是top import/include/using，那就挺自然的，没什么解释的必要了。所以将解释部分直接删除。