@mritd 对，这个我就比较不能忍…

作为一个包，居然还有外部不可控的依赖……

文件体积大小就算了，毕竟打包后的项目的体积还可控，但万一人家外部依赖的挂了。。。

开发都进行不下去了好吗！！

你还别说，我记得上次哪听说 Python 都要学着这么干了。
理由无非是全局的包和各个项目下的依赖不一样，大家现在都用 pyenv，venv，pipenv 之类的在不同项目中加载不同的，所以好像是 pip 还是啥的要搞一套类似 Node 这样的玩法，没指定走全局，当前目录下有的话走当前目录…还能方便打包 blahblah，毕竟你看 electron 那带的东西。

道理是对的，但我总觉得哪里还是有点不对劲。好像可以有更省事的方法来着。

前端你再怎么处理基本也是传 base64 去后台了。。。

不如交给后端做更好了。

@whoami9894

我会觉得靠别人的图床不可靠。随时可能挂，就像你现在遇到的这样。

所以我会不怕辛苦的搞两份备份，因为我个人觉得这是一个正常人该考虑到的情况——万一那货挂了呢？居安思危才是正常心态。

但不这么干也没问题……毕竟不以正常分，大多数人确实是懒，不愿意搞两份，确实麻烦…我当年也像你这样，还想侥幸。

连续五六年挂了七八家外链后我彻底放弃，老老实实搞两份。

所以楼主大可不必像我这样搞。人生就是这样，哈哈哈，吃的亏不够多，就还会有侥幸心理。再来几次我相信你会和我一样，老老实实搞多个备份。如果觉得还不想这么搞，就说明吃的亏不够多，挨的打不够疼，丢的数据还不够肉痛…

但那一天迟早会到来 23333

VSCODE 内存占起来比我的 JB 系列 IDE 高。。

Gvim

我一个 30 多岁的人为什么要点进这个帖子。。

有同样困扰的不止我一个。。。

至少我听说在玩 FPS 游戏的时候，120Hz 是能够让人更精准的捕捉高速移动物体的。

我记得还是有差别的。。需不需要走网卡。。。

没啥好嘲笑的，小白这东西，拦一个是一个。

小白如果自己愿意上网查找答案，发现原来可以轻松破解，那也是好事，那意味着小白也多少学到了一点点新东西。

所以其实拦的不是小白，是某种意义上的伸手党，F12 一按就想抄。同样都是小白，能自己找寻破解方法和不愿意找的还是不一样的。

aveline

朋友，我觉得真的高并发的话，可能你的问题首先不是出在 MySQL 上，而是 php-fpm 上……

当然我不知道你怎么部署的，如果真的若干机器堆住，一般 hold 住也没问题，当然真是这样的话那 Redis 啥的也不算事了。

毕竟不知道你的高并发首先有多高 - -#

切 CDN 是因为被 D 了么。。。

买，不要犹豫。
家里又不是没有这个条件。

@guijianshi01 哈哈哈，理解理解，我就这么过来的。我的做法不敢说是完美，也是一个一个坑才过来的血泪史。

最核心的，我称为核心功能接口，我是尽最大可能划分到最细的粒度，比如一个 auth，这类接口我设计的时候原则上是不直接暴露给前端调用的，因为直接暴露意味着给前端需要请求太多的内容，无论性能还是开发流程上都不可接受，前后端会打架的。

但这类接口也不绝对，某些高频，无法也无需改动的，比如授权，这种模式下我会适当直接传给前端。

然后核心功能接口写出来其实是为了给后端调用的，用来做各种业务接口组合。这里面也是血泪史，差点和后端打疯，后端说我几个 import 的事你非要我调网络请求的形式来（我们目前的能力只能以 RESTful API 的形式互相调用），包括业务接口不一次写完，而是写完再组合… 但最后后端发现，在不同的项目中，熬过前期后，往往重新组合包装一个接口提供给前端，会变的异常轻松。

当然这里也有 API 网关这个我 18 年年初才学到的概念的支援。包括我上面讲的模式里，其实在包装组合接口提供给业务用这件事上，前端突然发现他们也有能力直接调用以及做组合了，所以业务上其实突然变的相对好一些了。

但一个系统的总体复杂度是不变的，对应的，压力放到了我这边，我自己做的这个设计和决策，现在我要为统筹管理和理清这么多接口、模式进行负责，这个压力也大。可总比和大家一起开会分析那绕来绕去的业务逻辑还是要轻松一些的。

所以我写了这么多，其实也没有直接回答你的问题。全部写一起肯定是弊大于利，畏手畏脚，甚至逼不得已要重新写一个新的大的单体出来。拆开的不合理的话，又会东改西改，并且接口功能重复，模糊，界限不清。

但就我自己的经验而言，还是要拆，拆的时候优先提炼出核心的不变的东西，尽可能在少增加额外开发的情况下将接口复用组合提供出业务接口来。而且业务接口尽量不要由核心系统直接提供，一定要有个 API gateway 层，让这个层来承担接口的分发工作。 我们用的也不好，业务中有大量冗余接口，也有很多沉没的存在安全隐患的东西，这个以后早晚要慢慢解决。但小公司，四五个人的团队，只能先到这样了。

也是老生常谈的话题了，讲的其实挺没意思的。

说到底啊，这行业的业务变化啊，太快了。。唉，做的累。

这个我有话要说。

我就干过类似楼主领导的事，要求别人（最后因能力问题搁浅，后来重新慢慢尝试，小步慢跑）。

中间不同的项目里反反复复很多次。

目前我仍然持有和楼主领导接近的想法，但不再那么激进，会根据实际情况进行调整和妥协。

但从一个系统架构设计的角度来看，我仍然认为拆分利大于弊，包括这种有人认为的过度设计的部分。首先过度设计就是个并没有绝对标准的东西，怎样算是过度的设计？

在项目进度允许，团队成员能力足够的情况下，一个总体复杂度为 10 的东西，而这个复杂度其实是大致可以预见到的，比如 3 个月做出来这个东西，相对可控，但 3 个月后这个项目会变成什么样，怎么发展，我不可预知，不可控，那就不考虑那种做成运行几年，团队扩充到 20 人的事。 但这 3 个月内可能会有的变动，模块和组件的拆分，部署的调整，哪些事情我提前做是可以预留的，这个讲实话，我是觉得需要很深厚的经验积累的。而运用的恰到好处的话，对团队，项目都是有极大的好处。

也就是说，我并不赞同一上来把整体复杂度为 10 的单体应用拆成 10 个 复杂度为 1 的模块，但根据实际情况，拆成一个略小的复杂度为 5 的小单体+ 5 个复杂度为 1 的小模块，是不是会更有利于项目推进、迭代试错、能力培养呢？

而且在开发周期较长的项目里，不考虑因为拆分带来的额外复杂度的情况，就项目本身而言，经常是这么一个转换节奏：

5 +3 + 2
5 + 1 + 1 + 1 + 1 +1
4 + 1 +1 +1 +1 +1 +1
4+ 2 + 2 +1 +1
3 + 1 +1 +2 +1 +1 +1

也就是楼上有人说的那句话，合久必分，分久必合。楼主的领导可能有过度设计的嫌疑，但楼主这种一个大单体的思路其实也有些理想化了——什么项目都经不起变啊，变着变着就要了亲命了，尤其是前端这种没有好的工程化体系的地方（不管 webpack 有多强，vue 多好用，只要还是 js，就注定没有好的工程化的基因）。

当然，我说了也白说，领导最大，木已成舟，估计楼主应该已经吭哧吭哧的做了蛮久了……