我用道具就是绿巨能。

提醒拆的时候螺丝刀不要乱碰，我就是拆的时候碰到短路，起火……

本来 300 块搞定的换电池，愣加了 2000 自己换了屏幕。

其实点进来之前我本来是以为可以看到一个励志的成功故事的……

给不了楼主什么建议，但我可以讲一讲和技术周边相关的行业。

曾经很长一段时间，被互联网创业风潮洗脑的我，一直以为开发+运维+设计+销售+客服+PM 等这几个职位加起来，应该就是当下开发相关和周边的全部了吧。

后来才知道不是这样的。项目经理，产品经理，助理，总监，平面设计，UI 设计，这个那个，在不同的公司里有些时候有职能交叉，但总的来说和技术相关的或者说技术人员可能碰到和交流的岗位是很多的。

我以前对技术支持的理解和楼主的理解可能没差太多，甚至某些时候和高级网管可能页差不多吧。后来我才知道，还有另外一种技术支持。

比如说一个做 TO B 软件的公司，软件卖给了客户，卖出去了没完，需要有产品说明书（啊，其实和写技术文档有点接近），需要上门给客户做使用培训，需要有人做技术支持，对接（其实就是当客户遇到使用问题的时候，简单的快速上手教客户怎么用，或者问题严重要能准确定位问题，但具体开发和修复可能交给别的人）。 这种技术支持，更像是利用一个有技术基础的人对问题和软件的理解，来更好也更高效率的给别人反馈问题，解决客户遇到的问题和烦恼。

嗯，一种很“软”的技术行业，但其实很重要，在很多场合不可或缺的哦。收入，地位，在客户那的认可度，也是相当高的。

对，我知道我举这个例子和楼主想做的技术支持可能不一样，但我看也是不太想做一线开发，更希望在已有的技术基础上，能更物尽其用的发挥自己的能力。所以建议你找工作的时候可能可以看看这些“外延”的工作和岗位。我举的例子只是冰山一角，肯定还有更多种类的。希望能对你有帮助。

而且你也在通过学习和提高自己，以后的路应该可以更宽。说不定洗车这事不小心也能成为你的历练之一呢哈哈哈哈哈哈哈。

开发当然很好，做运维也很有乐趣。做不那么 hardcore 的技术周边工作同样也可以很好的。毕竟职业不分贵贱，劳动最光荣。楼主加油。

@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 层，让这个层来承担接口的分发工作。 我们用的也不好，业务中有大量冗余接口，也有很多沉没的存在安全隐患的东西，这个以后早晚要慢慢解决。但小公司，四五个人的团队，只能先到这样了。