在nodejs每个文件中都有一个module，它有自己的变量范围。当您将变量导入文件（React例如）时，您将此变量添加到module范围，而不是全局范围。

如果webpack您可以使用providePlugin轻松地使React变量成为全局变量：

new webpack.ProvidePlugin({
  React: 'react' // ReactJS module name in node_modules folder
})

之后，您可以跳过React在所有module中导入变量。Webpack将在需要时自行完成。

如果使用JSXand babel，则必须React在每个文件中导入，因为babel-preset-react会将JSX代码转换为React.createElement()调用，因此此代码

const Foo = () => <h1>Test</h1>;

将会

var Foo = function Foo() {
  return React.createElement(
    "h1",
    null,
    "Test"
  );
};

演示：Babel REPL

这就是为什么React应该在适当的范围内访问的原因，一种方法是在文件中导入 React。

问题的根源是依赖管理之一——作为作者，我如何描述和获取在我的“事物”（应用程序/组件/module）中需要的外部依赖来完成它的工作？

JavaScript 受益（或受害）有一个全局命名空间，可以在其中注入依赖项。虽然这通常可以在短期内简化依赖项管理（例如，您可以忽略它并期望在全局命名空间中提供您需要的所有内容），但随着应用程序的增长和变化，它通常会导致问题。例如，给定一个有多个贡献者的应用程序，人们可能决定更改应用程序的一部分以不再使用特定的依赖项，因此将其删除。如果应用程序的另一部分需要它，但该依赖项没有在任何地方正式声明，则很容易错过它。

为了做好依赖管理，每个离散的“事物”都应该独立于任何其他“事物”来描述它的依赖关系，这样它就可以在任何给定的上下文中安全地使用。这确保了每个“事物”无论如何使用以及它的“父”（导入“事物”的代码）具有什么，都完全具有它所需要的东西。

这种方法的替代方法是依赖注入。在这个模型中，“事物”提供了一个接口，用于将依赖项从消费者传递给“事物”。这有超出您问题范围的灵活性和可测试性优势。:)

// export a function that expects the React and PropTypes
// dependencies to be injected as parameters and returns
// the component rather than importing the dependencies
// and exporting the component
export default (React, PropTypes) => {
  return class extends React.Component {
    static propTypes = {
      name: PropTypes.string.isRequired
    }
    render () {
      return (
        <div />
      );
    }
  };
};

总而言之，让每个“事物”导入自己的依赖项在某种程度上是一种“安全措施”。它让您可以安全地重构您的代码，而无需记住提供这些依赖项的内容的认知开销。

原因是为了避免不必要的编译一个你不必编译 jsx 的 JavaScript 代码。例如，你有一个文件有一个函数可以添加，或者任何不需要编译 jsx 的函数，那么你不要把import React from 'react'放在那个文件的顶部。这将节省您的编译时间。