Jynxio

@georgeok 如果需要退款的话，发邮件给 Apple Support ，发的早就会退。另外，就算退了之后再订阅，事情还是一样的，我当初连退了三次，没有解法。

你更换了 ChatGPT 帐号，对吗？

ChatGPT Apple 端的订阅有 Bug ，充值帐号总会是 Apple ID 的首个充值帐号。两年前就有人发现了该 Bug ，直到半年前仍在，我猜现在也还没修。

Hi, @Livid

请问你有开源这些词条吗？

我觉得这种设定是合理的诶！因为这样才契合「让写 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

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