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` 是公有的。

还是有点矫枉过正了，看了原文，也收集了相关资料给 AI 评估，AI 的结论和我的想法是一致的 不能一概而论，日常使用 angular 作为基础框架，它里面就有各种黑魔法 这段评论没有测试数据支持，也只能算空对空的讨论 下面贴一段 AI 答复，和我结论是一致的，但比我表述的更清楚 ``` 所以,我的核心问题,下面的表述到底对不对? ``` ``` 如果用代码说话，你不应该使用这样的写法 import { a, type B } from '@/x' 而是删掉你的 index.ts ，换成 import { a } from '@/x/a' import type B from '@/x/b' ``` ``` 你的这段表述方向上正确，但不是“放之四海皆准”。更准确的说法是： - 在大型应用/仓库里：删掉 index.ts 、改成直达路径导入，通常更快、更清晰、依赖更可控。 - 在库（ library ）对外 API 聚合场景：保留 index.ts 作为入口更合理（对外稳定 API 面）。 - 在小项目或强缓存工具链下：差异可能不明显，但直达导入依然更透明。 所以你的写法更像强烈建议，而不是“唯一正确”。建议改成： > “在应用代码中尽量避免 barrel ，改成直达导入；库的公共入口除外。” 另外两个细节： - import type 也会参与模块解析，并不一定避免模块图膨胀。 - 不同 bundler/配置表现不同，所以“必然更快”不严谨，但大项目里通常更快是成立的。 如果你想，我可以把这段话润色成一段更严谨、可直接引用的版本。 ```

@Ketteiron 如果 export default 的话，你导入任何名字都可以啊，除非你先写组件，然后靠 ide 的提示引入

@Ketteiron 需要 index 文件的也是因为组件还要细分组件才这样，如何单个文件就能实现，那完全不需要，直接 export default 就行了

@Jynxio #10 > 标明代码的访问权限 对于模块内，不 export 就等于私有 对于 monorepo 可以使用 package.json 的 exports 来声明外部访问列表 如果是想禁止跨模块引入，可以用 eslint https://github.com/javierbrea/eslint-plugin-boundaries 重新导出的问题在于它只提供了一个大家约定好的入口，不能真正禁止外部引用，即使没有在入口导出，也可以全路径导入

@SanjinGG #13 我的建议是不要 export default ，使用具名导出 export { xxx }，这样可以随时重构变量名，而默认导出做不到 编辑器会收集全部 export 对象作为快速导入的候选列表，因此只要导出一次就够了，重复导出+默认导出一起用经常会遇到奇奇怪怪的 bug 。