Jynxio

我觉得这种设定是合理的诶！因为这样才契合「让写 Markdown 就像写 Word 一样」。

@Ketteiron

这是有道理的，我也赞同。

我再叠甲一下：我也不鼓励用 Barrel Files ，但一两万来行代码的项目可以不讲究。

@Ketteiron

赞同，约定确实是脆弱的。

我意识到这个问题后，就编写了 ESLint 插件来把「约定」变成「规定」。

谢谢你推荐的 ESLint 插件，我会仔细看它。

1. Barrel Files 不是反模式
2. 社区不推荐它，是因为 Bundler 的性能问题
3. 拖慢 Bundler 的 Barrel Files 主要来自库，而非业务代码
4. 业务代码的 Barrel Files 可能会引入更多的库，然后重复 3
5. 如果明确是小项目，那么随便用 Barrel Files ，否则别用

- - -

另外，Barrel Files 最有用的地方是标明代码的访问权限 那些被重导出的代码才是共享的，其余都是私有的。这可以避免某个功能的私有代码被另一个功能调用。

如果想实现这种效果，Barrel Files 是比较经济实惠的方案，而且 Bundler 对 Barrel Files 的优化还行，所以我才推荐「小项目随便用 Barrel Files 」。

我现在的确不用 Barrel Files 了，因为想避免项目膨胀成大项目后，要返工撤销 Barrel Files 。我现在用下划线前缀（`_`）来区分私有代码和公有代码，比如 `_private.js` 是私有的，`public.js` 是公有的。

@zhengfan2016

同意，然后我会这样做「旧项目用了就用下去，新项目就直接用更现代的」。

另外，Antd 自己本身性能就差，尤其是那个菜单组件。

个人建议，Antd 过时了很久了，逃。

React 自己的渲染机制决定的。

React 内部用链表维护了一个树，用来映射 DOM 和更多东西（比如 Context 、Portal 、Fragment 等这些），你每次更新 React 的状态，React 都会从顶开始检查这棵树的每个节点，如果节点上的数据变了，那么就运行这个节点对应的组件（就是你写的 React 组件）。


然后，你不写 Memo 、useMemo 的话，你的子组件就必然会跟着父组件的刷新而刷新，哪怕子组件的 Props 没变（为什么会这样？因为父组件传递给子组件的 Props 是一个对象，虽然这个对象的内容没变，但是对象自己不断的变）。

于是，你就会发现，React App 一定有超多的冗余执行，这就是为什么 React 慢的其中一个原因。

另外，React 那个树不是只遍历一遍的，他有时候还会回溯或者干脆从头再来。

就是这么个渲染机制，导致 React 很难写丝滑。

卡还是小问题，现在可以套 React Compiler ，问题是这个反复更新的渲染机制会让开发很复杂，比如 Effect 一多组件的行为就越难预测。

我是一边用，一边忍，一边推荐给别人... 因为生态比别的 UI 库繁荣太多太多了。

乙方的乙方就是项目外包 ^ ^

24 寸的 5k 屏幕才能达到果屏幕的像素密度