你好呀，我是歪歪。

最近遇到一个生产问题，我负责的一个服务触发了内存使用率预警，收到预警的时候我去看了内存使用率已经到了 80%，看了一眼 GC 又发现还没有触发 FullGC，一次都没有。

基于这个现象，当时推测有两种可能，一种是内存溢出，一种是内存泄漏。

好，假设现在是面试，面试官目前就给了这点信息，他问你到底是溢出还是泄漏，你怎么回答？

在回答之前，我们得现明确啥是溢出，啥情况又是泄漏。

• 内存溢出（OutOfMemoryError）：内存溢出指的是程序请求的内存超出了 JVM 当前允许的最大内存容量。当 JVM 试图为一个对象分配内存时，如果当前可用的堆内存不足以满足需求，就会抛出 java.lang.OutOfMemoryError 异常。这通常是因为堆空间太小或者由于某些原因导致堆空间被占满。


• 内存泄漏 (Memory Leak)：内存泄漏是指不再使用的内存空间没有被释放，导致这部分内存无法再次被使用。虽然内存泄漏不会立即导致程序崩溃，但它会逐渐消耗可用内存，最终可能导致内存溢出。

虽然都与内存相关，但它们发生的时机和影响有所不同。内存溢出通常发生在程序运行时，当数据结构的大小超过预设限制时，常见的情况是你要分配一个大对象，比如一次从数据中查到了过多的数据。

而内存泄漏和“过多”关系不大，是一个细水长流的过程，一次内存泄漏的影响可能微乎其微，但随着时间推移，多次内存泄漏累积起来，最终可能导致内存溢出。

概念就是这个概念，这两个玩意经常被大家搞混，所以多嘴提一下。

概念明确了，回到最开始这个问题，你怎么回答？

你回答不了。

因为这些信息太不完整了，所以你回答不了。

面试的时候面试官就喜欢出这种全是错误选项的题目来迷惑你，摸摸你的底子到底怎么样。

首先，为什么不能判断，是因为前面说了：一次 FullGC 都没有。

虽然现在内存使用率已经到 80% 了，万一一次 FullGC 之后，内存使用率又下去了呢，说明程序没有任何问题。

如果没有下去，说明大概率是内存溢出了，需要去代码里面找哪里分配了大对象了。

那如果下去了，能说明一定没有内存泄漏吗？

也不能，因为前面又说了：内存泄漏是一个细水长流的过程。

关于内存溢出，如果监控手段齐全到位的话，你就记住左边这个走势图：

一个缓慢的持续上升的内存趋势图， 最后疯狂触发 GC，但是并没有内存被回收，最后程序直接崩掉。

内存泄漏，一眼定真假。

这个图来自我去年写的这篇文章：《虽然是我遇到的一个棘手的生产问题，但是我写出来之后，就是你的了。》

里面就是描述了一个内存泄漏的问题，通过分析 Dump 文件的方式，最终成功定位到泄漏点，修复代码。

一个不论多么复杂的内存泄漏问题，处理起来都是有方法论的。

不过就是 Dump 文件分析、工具的使用以及足够的耐心和些许的运气罢了。

所以我不打算赘述这些东西了，我想要分享的是我这次是怎么对应文章开始说的内存预警的。

我的处理方式就是：重启服务。

是的，常规来说都是会保留现场，然后重启服务。但是我的处理方式是：直接执行重启服务的预案。没有后续动作了。

我当时脑子里面的考虑大概是这样的。

首先，这个服务是一个边缘服务，它所承载的数据量不多，其业务已经超过一年多没有新增，存量数据正在慢慢的消亡。代码近一两年没啥改动，只有一些升级 jar 包，日志埋点这类的横向改造。

其次，我看了一下这个服务已经有超过四个月没有重启过了，这期间没有任何突发流量，每天处理的数据呈递减趋势，内存走势确实是一个缓慢上升的过程，我初步怀疑是有内存泄漏。

然后，这个服务是我从别的团队那边接手的一个服务，基于前一点，业务正在消亡这个因素，我也只是知道大概的功能，并不知道内部的细节，所以由于对系统的熟悉度不够，如果要定位问题，会较为困难。

最后，基于公司制度，虽然我知道应该怎么去排查问题，命令和工具我都会使用，但是我作为开发人员是没有权限使用运维人员的各类排查工具和排查命令的，所以如果要定位问题，我必须请求协调一个运维同事帮忙。

于是，在心里默默的盘算了一下投入产出比，我决定直接重启服务，不去定位问题。

按照目前的频率，程序正常运行四五个月后可能会触发内存预警，那么大不了就每隔三个月重启一次服务嘛，重启一次只需要 30s。一年按照重启 4 次算，也就是才 2 分钟。

这个业务我们就算它要五年后才彻底消亡，那么也就才 10 分钟而已。

如果我要去定位到底是不是内存泄露，到底在哪儿泄露的，结合我对于系统的熟悉程度和公司必须有的流程，这一波时间消耗，少说点，加起来得三五个工作日吧。

10 分钟和三五个工作日，这投入产出比，该选哪个，一目了然了吧？

我分享这个事情的目的，其实就是想说明我在这个事情上领悟到的一个点：在工作中，你遇到的问题，不是每一个都必须被解决的，也可以选择绕过问题，只要最终结果是好的就行。

如果我们抛开其他因素，只是从程序员的本职工作来看，那么遇到诸如内存泄漏的问题的时候，就是应该去定位问题、解决问题。

但是在职场中，其实还需要结合实际情况，进行分析。

什么是实际情况呢？

我前面列出来的那个“首先，其次，然后，最后”，就是我这个问题在技术之外的实际情况。

这些实际情况，让我决定不用去定位这个问题。

这也不是逃避问题，这是权衡利弊之后的最佳选择。

同样是一天的时间，我可以去定位这个“重启就能解决”的问题，也可以去做其他的更有价值事情，敲一些业务价值更大的代码。

这个是需要去权衡的，一个重要的衡量标准就是前面说的：投入产出比。

关于“不是所有的问题都必须被解决的，也可以选择绕过问题”这个事情，我再给你举一个我遇到的真实的例子。

几年前，我们团队遇到一个问题，我们使用的 RPC 框架是 Dubbo，有几个核心服务在投产期间滚动发布的时候，流量老是弄不干净，导致服务已经下线了，上游系统还在调用。

当时安排我去调研一下解决方案。

其实这就是一个优雅下线的问题，但是当时资历尚浅，我认真研究了一段时间，确实没研究出问题的根本解决方案。

后来我们给出的解决方案就是做一个容错机制，如果投产期间有因为流量不干净的问题导致请求处理失败的，我们把这些数据记录下来，然后等到投产完成后再进行重发。

没有解决根本问题，选择绕过了问题，但是从最终结果上看，问题是被解决了。

再后来，我们搭建了双中心。投产之前，A，B 中心都有流量，每次投产的时候，先把所有流量从 A 中心切到 B 中心去，在 A 中心没有任何流量的情况下，进行服务投产。B 中心反之。

这样，从投产流程上就规避了“流量老是弄不干净”的问题，因为投产的时候对应的服务已经没有在途流量了，不需要考虑优雅的问题了，从而规避了优雅下线的问题。

问题还是没有被解决，但是问题被彻底绕过。

最后，再举一个我在知乎上看到的一个回答，和我想要表达的观点，有异曲同工之妙：

http://www.zhihu.com/question/63…

这个回答下面的评论也很有意思，有兴趣的可以去翻一下，我截取两个我觉得有意思的：

在职场上，甚至在生活中，一个虽然没有解决方案但是可以被绕过的问题，我认为不是问题。

但是这个也得分情况，不是所有问题都能绕开的，假如是一个关键服务，那肯定不能置之不理，硬着头皮也得上。

关键是，我在职场上和生活中遇到过好多人，遇到问题的时候，似乎只会硬着头皮往上冲。

只会硬着头皮往上冲和知道什么时候应该硬着头皮往上冲，是两种截然不同的职场阶段。

所以有时候，遇到问题的时候，不要硬上，也让头皮休息一下，看看能不能绕过去。

前端开发与组件库

注：全文所说的小公司特指：资源不足、技术能力不足的团队

在一些小公司的项目开发中，我们可能常常听到这样的想法：

• 我们公司的需求比较特殊，用现有的组件库不够灵活，不如自己封装一套！


• 现有的组件库样式不符合我们的产品需求，我们需要统一风格和功能，不如自己开发一套组件库吧！

以前我会很天真的支持这样的想法，现在，我会给提出者一个大嘴巴子！看似高瞻远瞩，实则全是陷阱，甚至可能成为整个团队的噩梦。

一个loading组件引起的生产事故

我先讲一个我们公司因为组件库导致的财产损失生产事故！

之前，我们业务有实现过一个表格，由于接口非常快，我们并没有增加loading样式。

代码实现也非常简单：

<template>

    <section class="table-section">

        <m-table :columns="columns" :data-source="tableData">

        </m-table>

    </section>

</template>

<script setup>

const tableData = ref([]);

const columns = []



const getTableData = async () => {

    // ...接口调用逻辑

    queryManageList()

};



// 获取表格数据

getTableData();



onMounted(() => {

  // 动态设置表头数据

  columns = []

});

    

</script>

m-table是我们公司的内部表格组件，上面的代码在生产稳定运行。随着数据的增多，接口有些慢了，于是客户希望加个loading。

我们公司的Loading组件模仿自Elemnet Plus，api的调用也非常相似

参考文档，代码的更改也就非常容易

<template>

    <section class="table-section">

        <m-table :columns="columns" :data-source="tableData">

        </m-table>

    </section>

</template>

<script setup>

const tableData = ref([]);

const columns = []



const getTableData = async () => {

   loadingInstance = Loading('.table-section');

   // ...接口调用逻辑

   await queryManageList()

  loadingInstance.destroy

};



// 获取表格数据

getTableData();



onMounted(() => {

  // 动态设置表头数据

  columns = []

});

    

</script>

代码看着严丝合缝，十分完美，然而，部署生产后，发现columns直接没了！

经过线上排查，发现loadingInstance = Loading('.table-section')这段代码直接替换了section标签内部的所有dom元素，造成表格的vue实例出现异常，onMounted钩子根本没有执行！

反观Element PLUS，人家直接是在section标签下生成的遮罩层，就不会存在这个问题！

小公司开发的组件，由于开发者技术参差不齐，很容易出现线上问题啊！这种问题在我们的日常开发中非常常见，害人啊！

为什么小公司不要轻易封装组件库

通过上面的案例，可以看出：小公司的开发人员技术参差不齐，组件库的质量也就无法得到保证。当然，技术还不是主要原因，毕竟技术是可以提升的，但下面的几个问题才是真要命的！

资源不足：人力和时间的双重消耗

封装组件库并非单纯的开发任务，它需要大量的人力和时间投入。对小公司而言，团队往往规模有限，开发资源紧张。

• 开发人员：为了封装一个组件库，原本负责业务开发的人员必须抽出精力进行组件封装工作，业务开发的进度被迫拖延。


• 时间成本：开发一个组件库不仅仅是写几个按钮或者表单，还涉及到设计体系、文档编写、单元测试、性能优化和浏览器兼容性处理等，这是一项长期工程。

就拿我们公司举例，我们一遍要写业务代码，一遍要维护组件，非常消耗时间！

就这，公司还不断地给我们加任务，把我们当牛马，直接开启996！

加班费没有我们就忍了，996一次不够，还梅开二度！

业务开发都没时间，还维护组件库，这不是自己坑自己么？ 小公司没钱没实力，再别开发组件库了，来来回回坑自己人！

维护成本高：一时造轮子，一世修轮子

自己封装组件库容易，但长期维护它却很困难。随着项目的迭代和需求的变化，组件库也需要不断更新和优化。

• 需求增加： 业务需求多样化导致组件库功能膨胀，原本简单的组件变得复杂不堪。


• Bug 修复： 自己封装的组件库缺乏大规模使用的验证，隐藏的 Bug 往往在上线后爆发，修复工作耗费大量时间。


• 兼容性问题： 浏览器兼容、新技术支持（如 Vue 3、React 18）的适配工作更是让人头疼。

我们的组件库更新非常频繁，因为随着产品的迭代，要增加很多新功能。有时候，为了使用组件的新功能或者样式，我们不得不升级组件版本。然而，有一次升级后，组件库内部存在严重bug，导致我们原有的许多界面崩溃，造成了重大生产事故！

这种组件升级导致的页面问题时常发生，加了一个功能，导致一个隐藏bug，后续为了解决这个隐藏bug，又引入其他bug，最终一个小功能要发好几个组件版本才能解决。我已经无力吐槽，害人啊！

而且，由于组件的功能不完善，经常要花费非常多的沟通成本

技术负债：短期便利，长期拖累

自建组件库在开发初期可能感觉很“顺手”，但随着项目规模扩大，组件库的缺陷会逐渐显现，成为团队的技术负债。

• 缺乏标准化： 自建组件库的规范不够完善，不同开发者在实现同一功能时可能写出风格完全不同的代码。


• 文档不足： 由于时间和人力限制，自建组件库的文档往往不完善，后期新成员加入时难以上手。


• 升级困难： 自建组件库的每次升级都可能影响到现有业务，增加维护和测试成本。

员工离职风险：组件库成孤岛

小公司人员流动较为频繁。

如果负责组件库开发的员工离职，组件库很可能会变成“孤岛”，无人维护，直接影响到项目的可持续性。

经济形式不好，我们公司近几年也裁了不少员，导致一些组件直接没人维护了，直接影响项目进度。

所以，资金、时间不充足，咱小厂还是别学大厂维护组件库了，要钱没钱，要时间没时间，来来会会坑的都是自己！

总结

封装组件库对小公司来说是一个高风险、高成本、低收益的选择。本人建议如下：

各位Leader注意，技术的最终目的是为业务服务！别为了凸显自己牛逼，强行开发维护一个组件库，最终只会害人害，搬起石头砸自己的脚！

小公司不要让组件库拖住脚步，把资源投入到更有价值的地方，才是发展的正确道路。

注：以上所有言论只针对公司的产品、项目而言！对于个人，你怎么玩都行，玩的越花越好，毕竟以后出去都是面试的资本！

啥也不是，散会！

写给我前端同事，从事一年多前端应该要怎么成长的路线

我知道在很多中大型公司，其实有好多领导前辈、以及师傅会给那些校招生，以及应届生规划一定的学习成长路线，可能还会有定期的大佬分享。有这么一个领路人、环境在其实成长是飞速的。

我入职了一家新单位，这家单位的没有太多规范，没有太多的组件封装积累，还会考核每周的代码量,我发现有些阶段代码量（测试阶段、需求阶段等）不够的时候大家都是往项目中塞没用的代码，还有些同学会复制公共组件的代码进自己的模块充代码，技术栈使用的是vue3 + js + ant-design-vue，一大部分人做的都是项目。

苏洋同学（化名）工作了2年左右，换过2家公司，第一家是个小公司也是在写一些后台管理的功能，这是他的第二家公司入职这家公司也有一年左右时间了。他逻辑，工作态度都没问题，也算是个积极上进的零零后好青年。他当前项目中的代码开发没问题，项目中多是一些业务表单，工作流之类的东西，有用户权限控制。有的时候他会请教我一些问题我俩也就从问题聊了聊技术，并且我把我的博客分享给了他，他说他有空会看看学习下。

我跟他从我的博客文章中聊了下他可能需要怎么做来获得成长，当然现在这个环境下我不能跟他说你多学一点可能工资就会高一些，假如在3年前我一定会告诉他，你学完这些其实可以换个公司去试试一定会比你现在的要高一点。可能学习完假如被迫换工作（裁员）了，机会会大点吧

大佬请绕路，我可能给的建议并不是最好的，但是我觉得对他来说现阶段是最使用的

针对他的成长经历规划

他的js基础可能没那么好，像一些数据处理上是有些问题，那么我建议他：

1. 重新学习下js针对数组,字符串等API，像字符串的cancat、includes、indexOf、lastIndexOf、endsWith、startsWith等等，像数组的forEach、map、filter、reduce、find、findIndex、some、every等等，他说他有些好像没有使用过。 学习了解用法，并且写一样的源码。例如：

解释
解释
'123'.endsWith('3'); // true



export const _endsWith = (source: string, target: string) => {

  const len = target.length;

  const substrValue = source.substr(source.length - len, len);



  return substrValue === target;

};



_endsWith('123456', '56'); // true

• 对堆和栈要有一定的理解，对深拷贝、浅拷贝有一定的理解。
• 对宏任务和微任务以及事件执行的理解。
• 对防抖和节流有一定的理解
• 对this有一定的理解并写出apply、call、bind的实现。
• 对类型判断instanceof、typeof、Object.prototype.toString.call等方法有理解。
• 对对象方法的使用Object.keys、Object.values、Object.entries、Object.assign等等

3. 去看下lodash的源码，例如：throttle、debounce、cloneDeep、groupBy、get、difference等等一些常用的方法函数要会写源码，最好自己写一遍。
   
4. 对正则表达式能对有一定的理解，并且写出一些常用的正则。
5. CSS 中对主题适配能有一定的理解，例如使用 less 和 Scss变量做主题适配，以及使用2套样式，或者使用css全局变量做主题适配。能区分出这几种的不同点

如果能把js的以上都能掌握了，那么你的基础算是扎实的了，差的可能就是工作经验以及深入了解一些框架的源码了。

6. 这个时候可以学习下代码规范了，其实vue的话可以看看element ui组件代码的规范，组件的设计以及源码具体。至少能实现message组件以及按钮组件
7. 学习下设计模式，例如：单例模式、策略模式、代理模式、发布订阅模式等等。
8. 可以多看看怎么写防御式编程，让你的代码更加健壮（这也就是为啥项目中bug多的问题，代码写的还不够严谨）
9. 可以去学习下TS,可能不用去特别做类型体操，基本的泛型能用，例如：Array、Record、Partial、Pick、Omit、Exclude、Extract等等。
10. 如果你对vue和react想深入研究，可以对比着使用看看它们之前的差异，有自己的认识。
11. webpack的配置，对打包优化有理解，对loader和plugin有理解，对打包工具有使用过。
12. 了解下npm,对npm 发布等命令有一定的理解，并且尝试自己发布一个包。
13. 对git提交规范有理解，并且使用。可以深入了解下git规范定义以及拦截。
14. 对 nginx 有一定的了解，并且使用。因为现在好多项目都是多页应用了，nginx就显得很重要了。
15. echarts 是图表库，可以学习下他的那些简单图表怎么使用canvas画出来的。

恭喜，假如你上面都能学会，我觉得你很了不起了，至少算是中级前端工程师。

16. 制定公司代码规范eslint, git 提交规范等等
17. git CI制定工作流是很重要的，可以学习下。
18. ...
19. ...
20. ...

结语

其实如果从事这个行业，可以把上面当作一个学习清单，然后按照顺序学习，这些都是必须且要学会的。然后把学习到的东西都记录下来。多总结，多思考，

作者：三原
来源：juejin.cn/post/7448899248475684899

就在刚刚，一个令人悲伤的消息传来。

谷歌 DeepMind 研究科学家 Felix Hill，于 2024 年 12 月 5 日英年早逝，年仅 41 岁。

自 2023 年初以来，他一直在与严重的精神疾病作斗争。期间，他表现出了重度抑郁和严重的自杀倾向，终于还是没有扛过去。

Felix 是一位学术成果颇丰的 AI 学者，谷歌总引用量为 19680，参与创建了自然语言理解基准 GLUE 和 SuperGLUE。

Felix Hill 本科在牛津大学学习数学，随后在剑桥大学拿到了语言学硕士学位，和计算语言学博士学位。

毕业后，他曾有 8 个月在高中担任数学老师，随后进入谷歌 DeepMind，当了将近 8 年的 AI 研究者。

消息传来，他的 AI 圈好友无不表示悲痛和难过。

1 月 11 日，Felix 的葬礼将于伦敦北部举行，届时将进行现场直播。

许多认识他的人悲痛地留言说：Felix 是一个很特别的人，超前于这个时代。

左右滑动查看

最令人心碎的博客

是什么样的原因，让这样一位成果丰硕的 AI 学者的生命逝去？

他生前的一篇博客，揭露了许多细节。

他详细描述了 2023 年母亲离世后，正在精神病院接受治疗的自己症状更严重了。接下来的 12 个月内，他更是陷入极度焦虑和自杀的抑郁状态。

他也写道，自己当初投身 AI 研究并不是为了赚钱，但 AI 大爆发后，自己仿佛被迫进入「战争」状态，写论文、搞研究、创业，都令人压力重重，找不到出路。

即使积累了大量财富，自己也依然出了问题。

文章地址：medium.com/@felixhill/…

英伟达高级研究者 Jim Fan 读完悲痛地表示：这是我读过最令人心碎的博客，因为它如此真实，如此贴近内心。

Jim Fan 表示，AI 不应该是 200B 权重的压力和痛苦。

曾经，这是一个充满咖啡因带来的灵光乍现的地方，是令人兴奋的深夜 arxiv 探索之旅，是能让研究者脸上露出笑容的绝妙想法。但所有涌入的资本和关注，似乎正在迫使每个人竞相逐底。

黄仁勋经常对员工们强调，不要用「打败这个，碾压那个」的措辞。因为大家的目的是为了提升整个生态，而不是让任何人陷入深渊。AI 学者的工作是做大蛋糕，越大越好，然后再分配。

AI 不是零和博弈，事实上，它可能是人类有史以来拥有的最正和的博弈。大家应该做的，是向竞争对手传递爱意。

Jim Fan 写道，虽然并未有幸在现实生活中认识 Felix，但自己很喜欢他的研究品味，为他的每一篇新论文都设置了 Google Scholar 提醒。他在 AI 智能体和 VLM 方面的工作也对自己影响很深。

「他本应该成为一个很好的朋友。我想认识他，但现在已经不可能了。」

「安息吧，Felix。愿来世你不需要去战斗。」

2000 亿权重的责任：现代 AI 工作中的压力

下面这篇博客中，Felix 详细回顾了 AI 爆火的几年，给自己的生活带来的剧变——

过去两年，AI 领域发生了不可逆转的变化。

ChatGPT 的月活数接近 2 亿人。Gemini 在 2024 年 5 月的访问量接近 3.2 亿次，AI 爱好者现在可以使用 AI 微波炉、AI 牙刷，甚至 AI 足球。

然而，对于我们这些在 AI 领域工作的人来说，这种大众兴趣的激增既是福也是祸。

诚然，薪资水平上涨了，股价和市值也随之提高。但另一方面，这种变化也带来了独特的压力。

这篇博客讲述的是现代 AI 领域的压力。它面向所有在 AI 领域工作的人（按保守估计，现在全球人口中大约有 87% 的人在从事 AI 相关工作），特别是那些从事 AI 研究的人。

最终，我希望通过讨论 AI 研究中的压力源，让我们这些有幸在该领域工作的人生活得更快乐一些。

因为，尽管目前一片混乱，这仍然是一个美妙而充实的职业——它有潜力解决科学、哲学乃至人类本身的诸多重大问题。

无处可逃

几个月前，我参加了一个朋友的 40 岁生日派对。在那些我不太熟悉的人中，我注意到一个奇怪的现象。

尽管我那时身体不适，而且明显不太想讲话，但我周围还是形成了一个包围圈，原因仅仅是，大家知道我在 DeepMind 上班。

而且，他们想聊的不是足球或 80 年代音乐，恰恰是我最想避免思考的主题——AI。

虽然很感激这么多人对我的工作感兴趣，但这也提醒我过去两年发生了多大的变化。

银行家、律师、医生和管理顾问都想听听我对 ChatGPT 的看法；虽然很少有人声称在工作中直接使用了 LLM，但他们确信，AI 领域正在发生一些他们应该了解的事情。

作为一名研究人员，我相信你也能体会到这种在社交场合无法放松的感觉。

但情况更糟。就连在自己家里，我也找不到安宁。

我早已不再看新闻，因为害怕引发焦虑。但即使是在看足球、VH1、蒙塔尔巴诺探长，或者那部出色的《那不勒斯四部曲》改编剧时，广告中也充斥着与 AI 相关的内容。

在这段时间，我时常幻想着收拾行李，跨越大洲去加入一个隐居群体。但很可能连内观禅修（Vipassana）也被 AI 渗透了，这不会让我惊讶。

无形的竞争

几家大公司竞相开发最大、最好的 LLM，这一事实本身就令人压力重重——无论你为哪家公司工作。

现在从事 AI 研究，感觉就像参与一场战争。希特勒和达奇 · 舒尔茨的例子告诉我们，参战可能导致精神病态、离婚和自杀等严重后果。

当然，我并不是要把参与 AI 研究等同于参与真实战争，但我的亲身经历却表明，这种类比是很真实的。

关乎底线的工作

通常，业界的研究人员并不习惯于自己的工作对雇主的底线产生直接且即时的影响。

当然，许多研究人员都梦想能够产生这样的影响。只是以前，这种机会可能是十年难遇。

如今，对 LLM 基础研究的结果，往往只会对模型性能产生微小、短期的波动。然而，由于公司估值与 LLM 性能（难以分割地？）挂钩，这些波动可能导致股价出现数十亿美元的起伏。

这种动态令人倍感压力，而且这也不是 AI 研究人员在研究生阶段、博士后期间，甚至在 2022 年之前的工作中所能预料到的。

**钱，**钱，还是钱

大多数 AI 研究人员，尤其是我们这些超过某个年龄的人，当初投身研究并不是为了赚钱。

做自己热爱的工作还能获得丰厚报酬听起来是个完美方案，但这也可能引发强烈的焦虑。特别是当推动你收入增长的外部因素不在你的控制范围内，且 / 或者这些因素让你对工作的热爱程度大不如前时。

无论 AI 是否与此有关，突然积累财富可能会导致各种问题，看看那些经过多年努力终于成名的演员或歌手就知道了。成瘾、感情破裂、友谊破碎，甚至自杀只是一些较为常见的症状。

这些症状，我确实都感同身受。

科学家角色缺失

LLM 的规模、简单性和有效性使得做出「相关」的「科学研究」变得困难，这里的相关指的是能立即改进 LLM。

领先的 LLM 研究人员已经开始认同 Rich Sutton 的「苦涩教训」：除了规模之外，几乎不需要任何创新。

而且，即使理论上可能存在实质性创新，实现它往往需要在不同条件下反复训练最大规模的 LLM。这甚至连最大的公司都负担不起。

对于一个「普通」的研究科学家来说，这感觉简直令人绝望。

对于习惯于在 5 至 10 人的小团队中工作的工业界科学家来说，这些已经很艰难。但学术界的人所遭遇的无疑更加严峻，比如那些博士生、博士后和 AI/CS / 机器学习领域的教职人员。

发表论文

虽然学术界的人可以（也应该）继续发表从 LLM 实验中获得的见解，但对于工业界的科学家来说，发表论文的问题就没那么明确了。

发表论文一直是科学过程的内在组成部分，也一直是 AI 研究的核心原则。我接触过的大多数 AI 研究人员，特别是研究科学家，都同意我的观点：发表论文是我们职业生涯的关键。

但是，至少在工业界，过去 2 年来，研究成果是否能够发表的问题变得越来越不明确。能够改进 LLM 的小技巧可能等同于 LLM 之战中的关键武器。将这些秘密公开是否对资助研究的组织有利，这始终是一个需要深思熟虑的问题。

这一切都意味着，研究人员经常对自己想法的前途毫无把握，至少，这会对我造成巨大的压力。

创业公司

当然，摆脱这些困扰的一个可行出路，就是规划科研方向，筹集资金并成立创业公司。事实上，目前 AI 创业公司（无论大小）的激增表明有多少科学家选择了这条路。

但成为创始人并不能必然地规避相关压力。

众所周知，创业的压力也很大；即使在当前投资者热情高涨的情况下，许多资金充足的 AI 创业公司仍然失败了。

我知道，成为创始人是一段特别孤独的旅程。这无疑是当下雄心勃勃的科学家们的一个可行选择，但这既不会让做研究变得容易，也不会减轻压力。

为什么要写关于压力的博客

过去两年在 AI 领域可谓混乱而疯狂，而对我个人而言，这更是一段特别动荡的时期。

2023 年 4 月，我的母亲在与阿尔茨海默症长期抗争后离世。那时的我正在精神病院接受治疗，因为出现了严重的精神症状，其中压力很可能是重要诱因。

在接下来的 12 个月里，表面上我是在康复中，但实际上却陷入了极度焦虑和自杀倾向的抑郁状态。

所幸在这期间，我遇到了非常理解我的处境（以及认可我对公司的价值）的雇主，他们一直为我提供治疗和精神上的支持。

经过另外 6 个月的重度抑郁之后，我的状况开始好转，最近也感觉自己有能力写下这些经历。

我深刻地认识到压力和焦虑是密不可分的；事实上，它们本质上可能是同一件事。诚然，像任何适应性特征一样，焦虑有时也能带来积极影响（比如提高生产力），但一旦焦虑变得失控，后果可能相当严重。

正是在尝试重新学习如何成为一名 AI 研究员的过程中，回顾 AI 领域这两年的发展，让我获得了这篇博客中所分享的见解。

诚然，仅仅分享这些见解并不能从根本上解决问题，但在最艰难的时期，能给我带来希望的少数事情之一就是意识到我并不是一个人在战斗。

如果你现在也在经历类似的困扰，请记住——你并不孤单。

社交焦虑

我已经讨论了当前从事 AI 研究的人可能遭受的诸多压力或焦虑的诱因。

然而，还有一种压力我尚未提及，这是因为我很幸运从未亲身经历过。我对它的了解，完全来自于与朋友和同事的深入交谈。

这种压力就是社交焦虑。

据朋友们反映，那些有社交焦虑的人往往会觉得群体互动充满挑战。在现代 AI 领域，这是一个格外严峻的挑战，因为大型项目团队和大规模的（通常是跨洲际的）协作已成为必需。

目前行业中的高流动率更是雪上加霜，因为已建立的团队（通常作为社交「安全网」）可能在一夜之间解散瓦解。

人员流动还可能引发信任危机，因为曾经可靠的伙伴可能会转投竞争对手的研究团队。

值得欣慰的是，社交焦虑和我此前讨论过的所有焦虑或压力表现一样，都是可以克服的。克服的第一步是培养以家人和「非 AI 圈」朋友为主的自然支持系统。

而关键的第二步，则是我们所有从事 AI 工作的人，都要开始并持续保持关于压力的坦诚对话。

因此，诚挚邀请你在社交媒体上分享自己的经历和感受。让我们携手努力，不仅将 AI 研究打造成一个充满活力和智力挑战的领域，更要使其成为一个充满同理心和善意的温暖家园。

AI 大佬发长文缅怀

Contextual AI 首席执行官 Douwe Kiela 发文表示，我真的很难过，我亲爱的朋友 Felix Hill 离开了我们。他在世界各地有很多朋友和同事。为了让更多人知道，他的家人希望我们分享这个网页，一起纪念他的一生：

EPFL 教授，前 DeepMind 研究科学家 Caglar Gulcehre 表示，听到 Felix 离开我们的消息，真是令人心碎！

他回忆道，「我第一次见到 Felix 是在蒙特利尔读博二的时候。那时候，我正经历抑郁症，头两年的生活很难熬。我搬到一个新国家，再加上冰天雪地的天气，让我感到特别不适应。

Felix 总是充满活力，乐观开朗。但有时候，你很难知道别人生活中正在经历什么。所以，对他人多一份理解，不要轻易下结论很重要。或许他们可能正经历着不为人知的困境。可惜的是，很多人仍然低估了心理健康的重要性。

寻求帮助并不是软弱的表现。刚到 DeepMind 工作的头两年，我的父亲突发心脏病，后来还失明了；我的姐姐也被诊断出癌症。那时候，我又搬到了另一个国家。如果不是寻求了专业帮助，我不知道自己该如何应对这一切。

无论何时需要帮助，都要勇敢去寻求。我很感激身边有许多支持我的人，在困难时期给予了我很大的帮助。如果心理状态不佳，很难在工作上取得成功。向 Felix 家人致以深切的慰问」。

DeepMind 研究科学家 Andrew Lampinen 发文怀念其这位曾经指导过自己的导师——

Felix Hill 是一位非常出色的导师——偶尔也是我的冬泳伙伴。我能加入 DeepMind，以及形成如今做研究的方式，很大程度上都要归功于他。都过去一个月了，我还是觉得难以相信他已经离开了。

Felix 在选择研究方向上有着超强的眼光，而且直觉特别准。每当遇到新想法，他总会表现出孩子般的热情和好奇心，还特别幽默，能够与他一起工作真的让人备受启发。

他也特别看重跟他共事的每个人。在我刚到 DeepMind 的时候，他和 Jane Wang 一起把一群超棒的人聚在了一起，比如 Stephanie Chan、Aaditya Singh、Allison Tam，还有其他很多朋友和合作伙伴。

不过他也经历过一段艰难时期，尤其是最近这几年。我最后一次和他聊天是在他离世前大概一个月，那时他跟我分享了一个雄心勃勃又有点疯狂的项目想法，让我仿佛看到了他当年的影子。但那会儿我太忙了，一直没有再跟进，直到现在为时已晚，至今这件事让我特别后悔。

纽约大学计算机科学和数据科学教授 Kyunghyun Cho 更是写了一篇长文缅怀逝者——「再见了，Felix」。

文章地址：kyunghyuncho.me/bye-felix/

这段文字写于 2024 年 12 月 9 日，但当时我既不愿意也无法接受所发生的事实，所以一直没有勇气发布。即便到现在，每当想起这件事，我的心仍然隐隐作痛。我选择在 2024 年的最后一天发布这段文字，以此缅怀 Felix。

时间回溯到 2014 年初夏。我当时在蒙特利尔大学担任 Yoshua Bengio 教授的博士后研究员，而 Felix 是一位刚刚抵达蒙特利尔的访问学生。

那时，我正在致力于开发一个能够处理长句子的神经机器翻译系统（Neural Machine Translation，NMT），为此我尝试了所有能想到的方法（注意力机制当时并不在其中，直到同年夏天 Dima Bahdanau 作为实习生来到蒙特利尔才有了突破）。

在这些探索性尝试中，我构思了使用门控卷积编码器（Gated Convolutional Encoder）来替代基于循环神经网络（RNN）的编码器。通过对门控机制施加适当的约束，我成功训练出了这个模型，并使其具备了一定的可解释性。

当 Felix 来到我的办公桌前，以语言学家和计算机科学家的身份做自我介绍时，我很兴奋地想要向他展示这个新模型所揭示的可解释结构。

于是我向他展示了：

Felix 以极其笃定的语气对我说，「Kyunghyun，语法并不重要」。这大概是我听过非韩国人中最标准的名字发音。

那一刻我就预感到，Felix 一定会成为我最好的朋友之一——事实证明，从那时起直到现在确实如此）。而他说的这句话，也在往后几年里频频出现在我的学术演讲 slides 中。

在我们共度的那些愉快时光中，除了进行深入却不失趣味的哲学探讨，我们也开展了一些研究合作。

除了共同发现的诸多有趣成果外，我们最具标志性的「贡献」反而是一个相当特别的现象：从 2016 年开始，我们无意中引领了一股持续 3-5 年的潮流，就是人人都仿佛着了魔似的要在论文中塞入一个装满海量数字的「超级大表格」（The Really Enormous Table）。

当时我们在写「Learning distributed representations of sentences from unlabelled data」这篇论文时，完全没想那么多，但最终还是放入了两个巨大的数据表格：

2018 年初，Felix 在 ICLR 的论文集中发现了好几篇包含「超级大表格」的论文，这让我们不禁哑然失笑。

即使在严谨的学术研究中，我们依然保持着这种愉快的合作方式。

时光飞逝，将近十年后，Felix 作为 2023 年拉美人工智能会议 Khipu 的组织者之一，邀请我担任演讲嘉宾。他兴致勃勃地向我描绘我们将要进行的活动：观看足球比赛，游览布宜诺斯艾利斯等等。

然而，当我在 2023 年 3 月抵达蒙得维的亚参加 Khipu 时，却发现 Felix 并未到场。其他组织者告诉我，他因为健康问题无法前来。那时的我还不曾想到，这竟是我最后一次有机会与他相见。

Felix 在 2023 年第二届 Khipu 上未领取的参会正件

2024 年 6 月，经过漫长岁月，我终于有机会造访伦敦，便给 Felix 发消息约他共进午餐。尽管我清楚见面的可能性渺茫，但我真的非常期待能与他相聚、畅谈，一起消磨时光。

我们上次见面还是在疫情之前，之后就只能靠偶尔的远程视频联系。我也暗自期待能看到他康复的喜人变化。

几个月后（2024 年 8 月），Felix 回复了消息，并为迟复致歉，这实在让人心疼。他还附上了一张我们的合影（不是 AI 生成的，但是 Felix「生成」的），唤起了我们上次在伦敦相聚的美好回忆。

左图：这是一张由 Felix 本人「生成」的与我的合影；右图：这是一张真实拍摄的 Felix 与我的合影

上周五，我收到了 Douwe 发来的 WhatsApp 消息。正是由于 Felix 在 2014 年的引荐，我才认识了 Douwe，并与他建立了深厚的友谊。我立即尝试联系 Felix，但不管是 WhatsApp 还是手机，都已经无法接通。

Felix，愿你现在已不再痛苦，在天国与母亲团聚。

参考资料：

http://www.paperlesspost.com/go/7BbrzXXh…

medium.com/@felixhill/…

x.com/DrJimFan/st…

x.com/kchonyc/sta…

x.com/douwekiela/…

一、开篇

  12月今年最后一个月了，相逢的人已走散，Q4的OKR已经定型了，很平淡无味、闲的无聊，提前写个年终总结吧。25年，再过一个月就35岁了，一个人来北京也已经11年了。年近末尾，思绪良多。回顾过去来看，这一年还真的经历了很多的事情，我的生活也发生了翻天覆地的变化！时光走笔，岁月成章，书写一本名为《我》的彩色童话，刻画属于自己的千种情绪、万般色彩。如果用一句话概括下过去的一年，那就是：力学笃行倍道而进，从不缺少挑战的勇气；脚步坚实步伐坚定，从未停止奔跑的脚步。

• 历经苦难，方知生命可贵！


• 承受困难，方懂世事艰辛！


• 无惧苦难，方能勇往直前！

二、历历在目，回首成长之路

2.1 天地风尘三尺剑，江湖岁月一诗篇

这个世界，人有万算，但却不如老天一算，做人要坦坦荡荡，做事要问心无愧。

  回顾2024年，经历了非常多的大事情，有幸这一年全家人平平安安，在稳步前进。算是折腾的一年，刚开年之初，就喜得医院三日游，还记得那晚独自一人站在窗口，望着远处的万家灯火。依然不记得当时在想什么，只记得呆呆的站了一晚。也许过去的23年命里跟小人犯冲，又喜得公司裁员大礼包。原本想新年之后在重新找工作的，可麻绳专挑细处断，厄运只找苦命人，3月又被迫到医院“营业”，好在“苍天有眼见可怜，善恶有报分两岸”，还是顺利从手术台上走下来。医院是离生死最近的地方，再次面对时，本觉得可以洒脱些，然而，不然！真的真的是再也不想去医院了！

  这一年，有过迷茫和无助，更多的是家里人带来的幸福和开心，有家人们的支持，也有了新的目标。也许是大病一场后，很多东西彻底的看清了、放下了。最大的问题是，今年颓废了，丢掉了自己的早起习惯，开始习惯性的熬夜娱乐，总是晚起床。有时候，我也会羡慕当初年少的自己，那时的自己，敢爱敢恨、敢打敢杀，更加不顾后果。而现在的自己呢，懂得控制自己的情绪，学会了顾全大局，也是能屈能伸。但这样的自己，也有弊端，隐藏了太多情绪，同时也控制了太多感情，活的也不如当初那般潇洒了。可没办法，成长，是人的必经之路，尤其是男人。成熟的男人，不能一味追求潇洒。他可以不已天下人的安危为己任，但至少要保障身边人的安危。为求生计赴他乡，今朝重温儿时梦，却已青丝染白霜。沧海桑田，世事变迁，回不去了，终究还是回不去啊……

  我单枪匹马的走到现在，任何人都不是我的靠山。苦，我吃了；委屈，我咽了……伤痕累累走到现在，流言蜚语又能奈我何！再穷，我也没有骗过朋友；再苦，我也没有坑过身边人；再难，我也没有算计过谁……其实，我更喜欢好多年前的自己，他比我有胆量，比我遗憾少，比我懂得少，比我相信的很多……

2.2 书海遨游，陶冶情操

读书百遍，其义自见。 ——《三国志》

  如今，手机已成为我们生活和工作的必需品，仿佛离开了它，就失去了飞翔的翅膀。我们依赖手机获取信息、沟通联络、娱乐消遣，几乎每一刻都离不开这个小小的屏幕。然而，这份过度依赖，却让我们的心灵逐渐陷入了一片荒芜之地。风沙漫天，孤寂如影随形，我们急需一股神秘而强大的力量，在这片荒芜中播撒希望的种子，使之绿意盎然，生机勃勃。这股力量，便是阅读。

  在这个快节奏的时代，我们或许会因为忙碌而忽略阅读的价值。但请铭记，无论生活多么喧嚣，都要为自己的心灵保留一片净土，用来播种那些能够滋养我们灵魂的书籍。我每天抽出半小时的时间，远离手机、电视等电子产品的干扰，静下心来读一本书。当沉浸在书海中时，我发现那些曾经困扰我们的烦恼逐渐消散，内心变得宁静而充实。让我暂时忘却现实的痛苦，在无形中给予我力量，教会我如何在困境中寻找出路，如何在绝望中看到希望的曙光。

  那啥，虽然 24 年阅读的书籍着实不多，大部分是闲书，惭愧惭愧，25 年要加油了，

三、我的程序人生

3.1 缘起性空，归来不少年

有所选择，有所放弃，做到“尽人事，听天命”就好了。

  岁月匆匆流逝，回顾这一年最大的变化就是心态也有所起伏，整体有点躺平了，研究技术的动力也消失了，职业发展上感觉有点停滞不前了，也不太能跟生机勃勃的年轻人一起卷了。还记得从医院刚回来的那几周，整天在家里拉着窗帘，除了吃饭就是躺在床上刷手机，让我尽可能分散注意力，减少内心的痛苦。但是这样的状态也不是事儿啊，那只能去找个工作先干着了。活下来，是我目前的首要任务。于是在网上海投了一遍，结果惨不忍睹，根本没几家公司招人，前前后后两个月，真正靠谱的面试就那么几家。好在等到7月底顺利拿了offer，重新踏上“牛马”的大道。薪资也没有原来的多，但是拿到offer那一刻我依然有些激动，我感觉我活下来了，不管怎样，现在能喘口气了。

  现在上班已经四个多月了，新公司挺好，不加班，基本上7点前就都走了。每天就是按部就班上下班，完成老板给的任务，其他的事情也不用自己操心，终于又做起自己熟悉且擅长的事情。如今逐渐适应了新公司的节奏，也算成功融入了团队，同时和同事相处的也十分的融洽。现在所在公司很少有加班的情况，回想上家公司总是天天加班到12点，劳心劳力而最后却卸磨杀驴。经过上半年的与天搏命、下半年奋发图强，关于工作我只有几点反思：

3.2 坚定持续，攻破重重难关

人生不可能一帆风顺，就像大海不可能风平浪静一样。在生活中还是会遇到很多的困难与挑战，但庆幸的是我都扛下来了~

  春耕夏耘，秋收冬藏。回望来时路，满心皆澎湃。我个人感觉今年几乎没有太多成长，并没有对于某项技术有非常深刻的理解或者突破，连博客的阅读量和涨粉量也是靠着之前的老博文来的。今年最重要的事情之一就是在新工作上稳定下来，当然这也是工作以来最不容易的一年。在这个飞速变化的技术环境中，在程序员的世界里，写代码、修Bug、加班常常成为了日常，作为程序员，技术更新的速度是无法忽视的。

  虽然已经34岁了，不能熬夜写代码了，但是我还是喜欢偶尔敲敲代码，还是期待代码运行起来的效果，排除bug之后还是会高兴，这大概就是程序人生的乐趣！前些天翻了翻前端历史，突然发现，前端的屎事💩的确特别多。前端折腾来折腾去，好在现在才略微回到正轨上。作为后端 Java 程序员的我，并不反对前端折腾，对一些清晰的方向，我们还是应该全力以赴去折腾的。单一技能已经不足以满足现代项目需求，尤其是在公司需要「全栈开发」的趋势下，拥有一定的跨领域能力是你脱颖而出的关键。而且编程领域的变化是快速且持续的，持续学习是程序员生涯中的重要部分。可以通过参加技术分享会、研讨会，阅读最新的技术书籍和博客，或者加入技术社区来保持与行业趋势同步。此外，还可以通过在线课程或认证来提升自己的技能，为未来职业生涯积累资本。

四、心怀远方，踏上逐梦之旅

既已达成目标，也绝不懈怠，做好规划，奔向下一个目标⭐

4.1 厚积薄发，突破自我

学如不及，犹恐失之。——《论语·泰伯》

  程序员的职业发展并非一帆风顺，许多人会在某个阶段遇到瓶颈，感到技术不再进步或工作内容重复。如果感觉工作内容乏味且没有新的挑战，可以尝试向上级申请更多复杂的项目或转向其他技术领域发展。接受新的挑战不仅能让你重新激发兴趣，还能快速提升技能。或者，也可以考虑参与开源项目，这不仅是学习新技能的绝佳方式，还能与其他开发者互动，团队协作、沟通能力等软技能更进一步。

  我自认为是一个爱学习的人，从事互联网行业以来，一直都是从事 Java 的相关工作，除此还系统学过React、JS等，浅尝即止的就不说了，每一项都投入了较多时间，在这些技术的学习高峰，估计能达到中级开发者的开发效率吧。但是随着时间的流逝，其中大部分都忘的差不多了，如果面试官问我相关问题，我大概率是答不出来的，重新去做相关事情也需要去温习才能想起，很多人可能也有类似的感觉。去年的未来展望是打脸了，不少原先的计划没有完成，还因为突发的安排打乱了原先自己的部署，不过失之东隅、收之桑榆，收获也不少，那么我对 25 年的展望如下（写委婉点怕打脸太狠）：

• 「学习 Python」：未雨绸缪，只盯着一个方向很容易触及天花板，真正有能力的人应博学多才，触类旁通，我差得远呢。


• 「保持阅读」：之前买的很多书籍、专栏、小册、视频什么的不能浪费了，要看起来了（收藏从未停止，学习从未开始 🤪）。


• 「锻炼身体」：经历那几年的疫情，大家也明白 🐶 命的重要，锻炼身体要坚持下来，行远自迩/


• 「保险」：在考虑是不是要给自己上一个保险，虽然还年轻。


• 「圆满」：

4.2 向上破圈，遇见无限可能

也是因着有这样的经历，我也去尝试了很多之前完全没有尝试过的事情，真正感受到了什么叫做【脱离舒适圈】

  25 年的我 35 岁了，算是半只脚已经迈过而立之年的门槛，但距离成家立业还隔着老远，父母将老未老，知己零落四散。说实话，我现在知道了，山的那边还是山，我不知道什么时候才能看到海，甚至我可能一辈子都看不到海了。确实事情有些多且似乎都很重要，罗曼·罗兰的一句话怎么说来着 「有些人二十岁就死了，等到八十岁才被埋葬」，但至少到目前为止，生活还没把我扼杀不是嘛哈哈～。

  在这个飞速发展的时代，我们生活在一个个无形的圈子中。这些圈子可能是由我们的职业、兴趣、社交圈子或其他因素所定义的。每个人都有自己的舒适区，舒适是堕落的开始，而开拓则是成长的基石。只有从旧圈子进入更高的圈子，你才会进步。敢于挑战自己，才能经历成长和蜕变，领略不一样的风景。摧毁那些限制你发展的信念，敢于跳出舒适区，勇往直前，闯出属于自己的天地！

五、新的一年，一起加油

  长路漫漫，奋斗不息。学会和自己和解，学会接受自己的平庸，但是依然要努力，毕竟在这个阴雨连天的环境下，没有伞的孩子只能努力奔跑。我们的目标不仅局限于眼前的山川，我们的征途是星辰大海。那是一片辽阔无垠的天地，充满了未知与挑战。乾坤未定，每个人都有成为黑马的潜力。胜负尚未分明，未来充满无限可能。

• 愿你展翅高飞，化作飞鸟翱翔，自由随风。


• 愿你扎根大地，长成参天大树，傲骨铮铮。


• 愿你扬帆起航，翻飞万丈理想，意气昂扬。


• 愿你手握星火，燃尽塞途荆棘，前路坦荡。


• 祝你每次前行都能通往心之所向，每刻驻足都能遍赏锦绣河山。行己所爱，爱己所行，所有遇见皆是最好的安排。

教科书中 SQL 例句通常都很简单易懂，甚至可以当英语来读，这就给人造成 SQL 简单易学的印象。

但实际上，这种三行五行的 SQL 只存在于教科书和培训班，我们在现实业务中写的 SQL 不会论行，而是以 K 计的，一条 SQL 几百行 N 层嵌套，写出 3K5K 是常事，这种 SQL，完全谈不上简单易学，对专业程序员都是恶梦。

以 K 计本身倒不是大问题，需求真地复杂时，也只能写得长，Python/Java 代码可能会更长。但 SQL 的长和其它语言的长不一样，SQL 的长常常会意味着难写难懂，而且这个难写难懂和任务复杂度不成比例。除了一些最简单情况外，稍复杂些的任务，SQL 的难度就会陡增，对程序员的智商要求很高，所以经常用作应聘考题。

这是为什么呢？

其中一个原因是我们之前讲过的，SQL 像英语而缺乏过程性，要把很多动作搅合在一句中，凭空地增大思维难度。

但是我们会发现，即使 SQL 增加了步骤化的 CTE 语法，面对稍复杂的任务时，仍然会写的非常难懂。

这是因为，SQL 的描述能力还有不少重要的缺失，这导致程序员不能按自然思维写代码，要换着方法绕。

我们通过一个简单的例子来看一下。

简化的销售业绩表 T 有三个字段：sales 销售员，product 产品，amount 销售额。我们想知道空调和电视销售额都在前 10 名的销售员名单。

这个问题并不难，可以很自然地设计出计算过程：

1．按空调销售额排序，找出前 10 名；

2．按电视销售额排序，找出前 10 名；

3．对 1、2 的结果取交集，得到我们想要的

用 CTE 语法后 SQL 可以写成这样：

with A as (select top 10 sales from T where product='AC' order by amount desc),

     B as (select top 10 sales from T where product='TV' order by amount desc)

select * from A intersect B

这个句子不太短，但思路还是清晰的。

现在，我们把问题复杂化一点，改为计算所有产品销售额都在前 10 名的销售员，延用上述的思路很容易想到：

1. 列出所有产品；

2. 算出每种产品销售额的前 10 名，分别保存；

3. 针对这些前 10 名取交集；

遗憾开始出现，CTE 语法只能写出确定个数的中间结果。而我们事先不知道总共有多个产品，也就是说 WITH 子句的个数是不确定的，这就写不出来了。

好吧，换一种思路：

1．将数据按产品分组，将每组排序，计算出每组前 10 名；

2．针对这些前 10 名取交集；

这需要把第一步的分组结果保存起来，而这个中间结果是一个表，其中有个字段要存储对应的分组成员的前 10 名，也就是字段的取值将是个集合，SQL 不支持这种数据类型，还是写不出来。

我们可以再转换思路。按产品分组后，计算每个销售员在所有分组的前 10 名中出现的次数，若与产品总数相同，则表示该销售员在所有产品销售额中均在前 10 名内。

select sales from ( 

    select sales from (

        select sales, rank() over (partition by product order by amount desc ) ranking

        from T ) where ranking <=10 )

group by sales having count(*)=(select count(distinct product) from T)

在窗口函数支持下，终于能写出来了。但是，这样的思路，绕不绕呢，有多少人想到并写出来呢？

前两种简单的思路无法用 SQL 实现，只能采用第三种迂回的思路。这里的原因在于 SQL 的一个重要缺失：集合化不彻底。

SQL 有集合概念，但并未把集合作为一种基础数据类型提供，不允许字段取值是集合，除了表之外也没有其它集合形式的数据类型，这使得大量集合运算在思维和书写时都非常绕。

我们刚才用了关键字 top，事实上关系代数理论中没有这个东西，这不是 SQL 的标准写法。

没有 top 如何找前 10 名呢？

大体思路是这样：找出比自己大的成员个数作为是名次，然后取出名次不超过 10 的成员

select sales from (

    select A.sales sales, A.product product,

        (select count(*)+1 from T

         where A.product=product and A.amount<=amount) ranking

    from T A )where product='AC' and ranking<=10

注意，这里的子查询没办法用 CTE 语法分步写，因为它用到了主查询中的信息作为参数。

或可以用连接来写，这样子查询倒是可以用 CTE 语法分步了：

select sales from (

    select A.sales sales, A.product product, count(*)+1 ranking from T A, T B

    where A.sales=B.sales and A.product=B.product and A.amount<=B.amount

    gr0up by A.sales,A.product )

where product='AC' and ranking<=10

无论如何，这种东西都太绕了，专业程序员也要想一阵子，仅仅是计算了一个前 10 名。

造成这个现象的原因就是 SQL 的另一个缺失：缺乏有序支持。SQL 继承了数学上的无序集合，与次序有关的计算相当困难，而可想而知，与次序有关的计算会有多么普遍（诸如比上月、比去年同期、前 20%、排名等）。

SQL2003 标准中增加的窗口函数提供了一些与次序有关的计算能力，这在一定程度上缓解 SQL 有序计算的困难，前 10 名可以这样写：

select sales from ( 

    select sales, rank() over (partition by product order by amount desc ) ranking

    from T )

where ranking <=10

还是要用子查询。

窗口函数并没有根本改变 SQL 无序集合的基础，还是会有许多有序运算难以解决。比如我们经常用来举例的，计算一支股票最长连续上涨了多少天：

select max(ContinuousDays) from (

    select count(*) ContinuousDays from (

        select sum(UpDownTag) over (order by TradeDate) NoRisingDays from (

            select TradeDate,case when Price>lag(price) over ( order by TradeDate) then 0 else 1 end UpDownTag from Stock ))

    group by NoRisingDays )

自然思维是这样，按日期排序后开始计数，碰到涨了就加 1，跌了就清 0，看计数器最大计到几。但这个思路写不出 SQL，只能绕成这样多层嵌套的。

这个问题真地是当作应聘考题的，通过率不到 20%。

这么一个简单的例子就能暴露出 SQL 缺失的能力，SQL 缺失的内容还有更多，限于篇幅，这里就不再深入讨论了。

反正结果就是，SQL 实现查询时无法应用自然思路，经常需要绕路迂回，写得又长又难懂。

现实任务要远远比这些例子复杂，过程中会面临诸多大大小小的困难。这个问题绕一下，那个问题多几行，一个稍复杂的任务写出几百行多层嵌套的 SQL 也就不奇怪了，过两月自己也看不懂也不奇怪了。

事实上 SQL 一点也不容易。

下面是广告时间。

SQL 很难写怎么办？用 esProc SPL!

esProc SPL 是个 Java 写的开源软件，在这里github.com/SPLWare/esP…

SPL 在 SQL 已有的集合化基础上增加了离散性，从而获得了彻底的集合化和有序能力，上面的例子就 SPL 就可以延用自然思路写出来：

所有产品销售额都在前 10 名的销售员，按产品分组，取每个组的前 10 名再算交集；

T.group(product).(~.top(10;-amount)).isect()

SPL 支持集合的集合，top 也只是常规的聚合计算，有了这些基础，实现自然思路很容易。

一支股票最长连续上涨了多少天，只要按自然思路写就行了

cnt=0

Stock.sort(TradeDate).max(cnt=if(Price>Price[-1],cnt+1,0))

SPL 有强大的有序计算能力，即使实现和上面 SQL 同样的逻辑也非常轻松：

Stock.sort(TradeDate).group@i(Price<Price[-1]).max(~.len())

一、实现一个快速评分组件

const getRate = rate => "★★★★★☆☆☆☆☆".slice(5 - rate, 10 - rate);

console.log(getRate(0)); // ☆☆☆☆☆

console.log(getRate(1)); // ★☆☆☆☆

console.log(getRate(2)); // ★★☆☆☆

console.log(getRate(3)); // ★★★☆☆

console.log(getRate(4)); // ★★★★☆

console.log(getRate(5)); // ★★★★★

这个都不用多解释了，简直写的太妙了！

二、巧用位运算

用位运算可以实现很多功能，比如乘2、除2（或者2的倍数），向下取整这些计算操作，而且性能很高！

let num = 3.14159;

console.log(~~ num);  // 向下取整，输出3

console.log(2 >> 1); // >>表示右移运算符，除2，输出1

console.log(2 << 1); // <<表示左3移运算符，乘2，输出4

并且，利用~符,即按位取反运算符（NOT operator），还可以和字符串的indeOf方法配合使用。

const str = 'acdafadfa'

if (~str.indexOf('ac')) {

  console.log('包含')

}

其实原理很简单，举几个例子大家就明白了：

• ~-1的结果是0。


• ~0的结果是-1。


• ~1的结果是-2，~2的结果是-3。

三、漂亮随机码

const str = Math.random().toString(36).substring(2, 10)

console.log(str); // 随机输出8位随机码

这个在要为每个用户生成一个随机码的时候特别好用，具体随机码多少位可以自己控制，如果要的随机码位数特别长，可以把这个函数多调用一次，然后把结果进行字符串拼接。

四、史上最NB的报错处理

try {

  const str = '';

  str.map(); // Uncaught TypeError: str.map is not a function

} catch(e) {

  window.open("https://stackoverflow.com/search?q=js+" + e.message);

}

这应该是史上最NB的报错处理了，一般来说，抛出错误时应该打印日志并上报，这里直接带着报错信息给人家重定向到stackoverflow去了，顺便stackoverflow搜索了下这个报错，直接搜一波错误解决方案，而且这个网站是全英文的，顺便还能学一波英语，对于开发者来说，这简直太妙了！不过记得上线的时候，记得在跳转前加一个if(process.env.NODE_ENV === 'development')，不然上到线上一旦报错可就惨了!

五、倒序排序的简写

const arr = [1, 2, 3, 4, 5];

for (let i = arr.length - 1; i >= 0; i--) {

    console.log(arr[i]);      

}

可简写为：

const arr = [1, 2, 3, 4, 5];

for(let i = arr.length; i--;) {

    console.log(arr[i]);

}

代码解释：

先来回顾下for循环的书写结构，即for (初始化表达式; 条件表达式; 递增表达式),初始化表达式只会执行一次，而条件表达式和递增表达式在每次循环时都会执行一次，而正好这个倒序循环的终止执行条件为i==0，所以就可以把条件表达式和递增表达式合而为一了，主打的就是一个简洁。

六、在控制台输出一个键盘图形

console.log((_=>[..."`1234567890-=~~QWERTYUIOP[]\\~ASDFGHJKL;'~~ZXCVBNM,./~"].map(x=>(o+=`/${b='_'.repeat(w=x<y?2:' 667699'[x=["BS","TAB","CAPS","ENTER"][p++]||'SHIFT',p])}\\|`,m+=y+(x+'    ').slice(0,w)+y+y,n+=y+b+y+y,l+=' __'+b)[73]&&(k.push(l,m,n,o),l='',m=n=o=y),m=n=o=y='|',p=l=k=[])&&k.join`

    `)())

这段代码会在浏览器控制台中打印出一个键盘图形，不得不说写出这段代码的人真的太有才了！

以上就是我总结的一些前端代码的风骚操作，大家有没有更风骚的操作呢？欢迎大家留言分享！

前言

上篇讲述了一位老哥的10年搬砖历程《不容易，35岁的我还在小公司苟且偷生》，有位小姐姐看了之后比较有感触，希望我能将她的故事也讲讲，看看能否有共鸣的朋友。

程序媛的前半生

我今年30岁，无房无贷孑然一身。

出生在95年的沿海小镇（隶属八山一水一分田的省份），我四岁那年父母终于如愿以偿地迎来了弟弟，从此以后弟弟就是家里的中心。

高考填报自愿的时候，想到远点的地方上大学，最终上了四川的一所院校。坐了将近三十个小时的列车，也就是那会儿才真真体会到了书上说的："我国地势西高东低，幅员辽阔"。

专业学的信息工程，大学那会班里男多女少，大家都挺照顾我的，性格也变得开朗了许多，谈了个男朋友，我们相约考个985院校的研究生。

那年春天，考研成绩出来，我没过线，他低空掠过，接受调剂到另一个省读研，然而正当我打算二战的时候，被分手了...

因为考研错过了秋招，春招也只剩了尾巴，也不打算二战了，家里人让我回去找工作，不过我还不太想回去，先找工作再说。幸好平时跟着班里的大牛们一起做过项目，项目虽小，但知其然也知其所以然，花了2个月终于找到一份前端的工作。

2018年入职成都北部郊县的一家小创业公司，公司主营业务是硬件，互联网软件是辅助，前端+后端也就6个人，没想到前端除了我还有另一个妹子。

那会工资比较低，自己也知道本身有几斤几两，为了节省开支，每天都带饭，当然每天也是按时下班，下班后先把第二天要带的饭菜准备好之后，再花一小时提升自己的技术（主要是看别人的轮子），最后边做面膜边刷美剧打发时间，直到窗外的喧闹声逐渐隐去，我也入睡啦。

平淡的日子真的淡如水，印象比较深的是有个晚上需要紧急修复Bug，要去公司对齐方案，尴尬的是，最终查出来不是我的问题。回家的路上，看着昏暗路灯下长长的影子，莫名的感觉害怕，越怕走的越快，越快影子越长，终于看到小区门口有个抽烟保安叔叔，赶紧飞奔过去。当进入小区的那刻，回过头来，却怎么也找不到影子了。从那时起，暗下决定，再也不加班了。

2020年7月，刚好在公司待了两年，周围的同事都换了一半的新面孔，不少同事去了南边，在小聚的时候他们说起了南边的机会比这多多了，让我考虑考虑。我也仔细思考了自己的处境，软件在这家并不是主营业务，想找一家纯互联网的公司，最主要的是这两年没有涨薪，新来的小伙伴工资都比我高，于是也暗中投递了简历。

运气不错，一个月内面了4、5家，最终选定了一家互联网公司，工资是上家的两倍，当时暗自感叹同一个城市差距咋那么明显。

新的公司，单单是前端的研发都有30+人，而这还只是成都分部的。刚开始很是珍惜这份机会，任劳任怨，偶尔也会加班表现一下。后面逐渐和同事们混熟了，才发现自己的工资就是垫底的存在，瞬间加班的动力跌至冰点。

在这公司接触了更多的业务，学习了很多技术知识，甚至知道有些同事大佬自己创造轮子。也许是我比较菜，或是我工资比较低，领导给我的任务都不会太难，我也没出过什么幺蛾子。每年都有涨薪的机会，当然每年都没我的份，在这块我是有心理预期的，因此也不会失落（或许是已经麻木了？）。

23年底开始，陆续有同事拿到了大礼包，甚至有一次我刚从厕所出来，对面的同事的工位就空了。问了才知道，谈妥了，立马走。

到了24年初，小组内陆续走了一半的同事，直属领导找我谈话问我想法，我说我比较懵，明明我在组内最菜，为啥走的不是我。领导说，相比而言你的性价比较高，我暗想：直说我薪资低呗~。

到了24年底，还暗自庆幸自己能挺过最艰难的一年，没曾想拿到了大礼包，没有任何挣扎，签协议走人。

休息了一个月，尝试投递简历，直到现在才有两次面试邀约，神奇的是这两家都会问我同一个问题：结婚了没，打算多久结？我：？？？

我决定了，以后进行自我介绍的时候先发制人，本人未婚未孕未育。

面试结果最终当然是不了了之了。

直到成为自由人才深刻体会到今年寒气之重，都结冰了。

经过了用人市场的洗礼，在三月份之前都不打算投递简历了，反正都是石沉大海。

刚好有时间多休息，多去看看以前没去的地方（虽然大部分是穷游），节后再做打算吧。

30岁的我，在人们眼中是个剩女。

30岁的我，阴差阳错学了技术。

30岁的我，没造过一个技术轮子。

30岁的我，远离家乡几千里。

30岁的我，在领失业保险金。

30岁的我，也许会离开这座城市。

30岁的我，祝朋友们所愿皆所得。

这是一篇迟来的 2024年终总结，从来没正式的为自己做过总结。

一、工作

2023年底，其实当时经过了几面之后，本来已经拿到了 Gitee(开源中国) 的 Offer，然后因为杭州有朋友说有项目，于是思考许久之后，还是决定来了杭州。

选择杭州放弃了深圳，我觉得应该还是这几个原因：

参与的工作和项目

1.1 老系统的维护和迭代

本身有一套基于 PHP 的灵工财税系统在生产上跑，需要进行日常的维护、迭代一些新功能。

系统周边还有一套 支付宝小程序 也在线上运行着。

1.2 新系统的设计与开发

基于老系统的业务需求，重新架构设计和开发了一套新系统：

• 使用 Java17 / SpringBoot3 / MySQL8 / JPA / Redis / RocketMQ 等后端技术栈对后台服务做支持


• 使用 Vue3 / Vite / TypeScript / ElementPlus 等前端技术栈对前端页面做支持

新系统前前后后开发和测试花了大概三个月的时间，技术团队人员 2 个全栈，两个产品，两个测试。

1.3 MCN机构主播平台

设计开发了一个 MCN 机构的主播社区，技术栈和上面新系统基本一致，主要实现了一个后台服务、一个 Web 端的管理系统、一个基于 uniapp 的 App，上架了 App Store，Android 端倒是没有直接上商店，提供的是 H5 官网直接下载 APK.

1.4 一些小工具

也做了一些公司内部很多小工具的开发，例如基于 小爱同学 的业务语音通知服务、Web 叫号服务（类似在页面上输入信息，指定公司内各个部门的小爱同学进行通知的功能）

也不停折腾了公司的一些 VPN 网络架构 局域网服务器架构 等工作，例如基于 vmware vsphere vcenter vsan 的超融合架构等。

用大模型搭了一些好玩的服务，比如 ts.hamm.cn java.hamm.cn 等

1.5 其他项目

也客串了一个前端，参与了公司其他小组的社交类产品的管理后台开发。

因公司有一个 AI 出海项目需求，预研了一个 AI智能体项目，主要是一些角色扮演的场景服务 （此处有狗头）。

二、开源

今年做了一些开源小项目，当然比去年的积极性要低了很多：

2.1 SPMS 智能生产管理

S-PMS (Smart Production Management System) 智能生产管理系统 ，是一个集成化、智能化的企业级应用软件，它集成了多个核心的生产管理模块，包括 制造执行系统 (MES)、仓库管理系统 (WMS)、企业资源计划系统 (ERP)、质量管理系统 (QMS) 以及 物联网管理系统 (IoTS) 等。

技术栈使用的也是和 1.1.2 中提到的一样。

其中完成了两个端的开发：

• 服务端：github.com/s-pms/SPMS-…


• 网页端：github.com/s-pms/SPMS-…

这个项目其实从 2013年底 就已经开始了，目前还在迭代中。

2.2 OllamaK

因为觉得其他的 Ollama iOS 客户端都不好用，然后自己花了几天时间写了个简单的 Ollama iOS 客户端。

Github: github.com/HammCn/Olla…

基于 Swift + SwiftUI 设计。

2.3 AirPower4T

AirPower4T 是一个基于 Vue3 TypeScript Element Plus Vite 的开发基础库，使用面向对象、装饰器、Hooks等开发模式，内置了数据模型转换、表格表单装饰器配置、加解密和编码解码、网络请求、权限管理等常见后台功能以及页面组件，助力后台类系统的前端开发效率，同时保障了优雅的代码质量。

Github: github.com/HammCn/AirP…

2.4 AirPower4J

AirPower4J是一个基于 Java17、SpringBoot3.x、JPA&MySQL 的后端开发脚手架，其中包含了一些 RBAC、请求验证、CURD封装、异常处理、多租户SaaS、加解密与安全、WebSocket等模块，以满足日常开发的快捷、稳健、标准化等要求。

Github: github.com/HammCn/AirP…

2.5 一些SDK包

2.5.1 WeComSDK

企业微信的 Java SDK 。目前是开发中，对 企业微信 的一些 OpenAPI 进行了封装。

Github: github.com/HammCn/WeCo…

2.5.2 WeComRobotSDK

一个很好用的企业微信机器人开发工具包SDK。也是发布到了 maven 仓库。

Github: github.com/HammCn/WeCo…

2.5.3 AirPowerJavaSdk

AirPower Java SDK 是基于 Java8 下用于快速对接 AirPower4J 项目中的开放应用的开发工具包，实现了与 AirPower4J 匹配的 AES / RSA 出入参加解密、参数签名、防止重返攻击、数据自动转换等功能，针对基于 AirPower4J 下的 Web 项目提供快速支持开放能力。

Github: github.com/HammCn/AirP…

三、写作

这一年免不了在掘金和其他社区摸了不少鱼。

3.1 掘金专栏

开了三个掘金的专栏：

3.1.1 《用TypeScript写前端》

本篇专栏主要讲解作者是如何大胆放肆的使用 TypeScript 面向对象思维来写前端的。

截止目前，共收录了 32篇 文章，订阅用户 500 人，希望能真正的帮到这 500 个订阅的朋友。

3.1.2 《来杯Java压压惊》

主要是分享一些用Java写后端的心得体会。

截止目前，共收录了 14篇 文章，订阅用户 6 人，因为是 11月 才创建的专栏，数据有些许惨淡。

3.1.3 《你好，全干工程师》

网络？运维？架构？产品？设计？可能这个专栏都有涉及到。

截止目前，共收录了 47篇 文章，订阅用户 21 人，数据也不是那么好看。

3.2 粉丝数据

截止目前：

3.2.1 掘金粉丝：800

3.2.2 Github粉丝：211 (@HammCn)

3.2.3 Gitee粉丝：887

3.2.4 公众号粉丝：3401 （@imHamm）

公众号的粉丝也不是很垂直，现在几乎不在公众号发布什么内容了。

3.2.5 微博粉丝：5000

（不垂直，已经不打算经营了，不再公开了）

3.3 阅读数据

截止目前，掘金阅读数据：

四、生活

杭州的生活很糟糕。特别是美食。

4.1 饮食问题

刚来的时候，还能维持每周两三次在家做饭炒菜，这几个月几乎没怎么在家做了，都选择了外卖或者在外面吃。

美团上拉黑了很多个商家了，实在是难吃。

4.2 日常出行

因为几个朋友都在一起，所以日常也基本都是在一块。一般也只在家、公司、附近商场、机场、火车站 这些地方。

日常没有什么出行的需求，但给老婆换掉了之前 我开的油车，换了 另外一辆油车。。。

（给家里添置了第二辆林肯了，蛮喜欢这个品牌的）

唯二在杭州较远的两三次出行：

4.2.1 灵隐寺

去过一次就不再想去第二次了。

4.2.2 乌镇

和重庆的磁器口差不多，没什么意思。

五、家庭

家庭是最重要的部分，所以选择放到最后说了。

5.1 儿子

儿子今年六月份三岁了，也上了幼儿园小班。

小子从小就聪明，情商也高。就是在学校不爱吃饭，还回家说学校的饭菜不好吃。

现在几乎能用英文从 1-100 读出来，一些颜色、水果、物体 也都能简单的表达了。

数学方面的话，10以内的加法没问题了，减法还不太会的样子。

5.2 老婆

家里最漂亮的女人。带孩子、上班都是她。

5.3 亲人

爸妈，岳父岳母依然是围着儿子在转，也慢慢的有了一些岁月老去的痕迹了。

依然是身体健康，这也就是最大的幸福。

5.4 离开了两个亲人

我这边的爷爷和外婆相继在今年离开了我们。希望他们在那边没有烦恼，快乐生活。

六、总结

这一年经历了太多，本文也是流水账的方式做了个年终的总结。

对2025年的期望，目前也还很迷茫。

先祝福吧：

希望儿子能健康快乐的成长，能学习到很多好玩的东西。

希望老婆依然是貌美如花，别被儿子整天的调皮折腾。

希望爸妈，岳父岳母，爷爷奶奶们身体健康，生活没有烦恼。

至于我自己，现在还没想好，但希望2025年工作上能有一些新的突破。

就这样，也祝所有幸福的人们，2025的愿望也都能实现。

前言

一朋友问我Try-Catch写多了会不会让程序变慢，我不加思索的回答肯定不会，毕竟曾经研究过Java异常相关的字节码指令，只要被Try-Catch的代码不抛出异常，那么代码执行链路是不会加深的。

可事后我反复思考这个看似简单实则也不复杂的问题，我觉得顺着这个问题往下，还有一些东西可以思考，如果你感兴趣，那就跟随本文的视角一起来看下吧。

正文

首先郑重声明，单纯的针对一段代码添加Try-Catch，是 不会 影响性能的，我们可以通过下面的示例代码并结合字节码指令来看下。

示例代码如下所示。

public class TryCatchPerformance {



    public Response execute(String state) {

        return innerHandle(state);

    }



    public Response innerHandle(String state) {

        // todo 暂无逻辑

        return null;

    }



    public static class Response {

        private int state;



        public Response(int state) {

            this.state = state;

        }



        public int getState() {

            return state;

        }



        public void setState(int state) {

            this.state = state;

        }

    }



}

我们依次执行如下语句为上述代码生成字节码指令。

# 编译Java文件

javac .\TryCatchPerformance.java

# 反汇编字节码文件

javap -c .\TryCatchPerformance.class

可以得到execute() 方法的字节码指令如下。

public com.lee.learn.exception.TryCatchPerformance$Response execute(java.lang.String);

  Code:

      0: aload_0

      1: aload_1

      2: invokevirtual #2                  // Method innerHandle:(Ljava/lang/String;)Lcom/lee/learn/exception/TryCatchPerformance$Response;

      5: areturn

现在对execute() 方法添加Try-Catch，如下所示。

public class TryCatchPerformance {



    public Response execute(String state) {

        try {

            return innerHandle(state);

        } catch (Exception e) {

            return new Response(500);

        }

    }



    public Response innerHandle(String state) {

        // todo 暂无逻辑

        return null;

    }



    public static class Response {

        private int state;



        public Response(int state) {

            this.state = state;

        }



        public int getState() {

            return state;

        }



        public void setState(int state) {

            this.state = state;

        }

    }



}

查看execute() 方法的字节码指令如下所示。

public com.lee.learn.exception.TryCatchPerformance$Response execute(java.lang.String);

  Code:

      0: aload_0

      1: aload_1

      2: invokevirtual #2                  // Method innerHandle:(Ljava/lang/String;)Lcom/lee/learn/exception/TryCatchPerformance$Response;

      5: areturn

      6: astore_2

      7: new           #4                  // class com/lee/learn/exception/TryCatchPerformance$Response

     10: dup

     11: sipush        500

     14: invokespecial #5                  // Method com/lee/learn/exception/TryCatchPerformance$Response."":(I)V

     17: areturn

  Exception table:

      from    to  target type

          0    5     6   Class java/lang/Exception

虽然添加Try-Catch后，字节码指令增加了很多条，但是通过Exception table（异常表）我们可知，只有指令0到5在执行过程中抛出了Exception，才会跳转到指令6开始执行，换言之只要不抛出异常，那么在执行完指令5后方法就结束了，此时和没添加Try-Catch时的代码执行链路是一样的，也就是不抛出异常时，Try-Catch不会影响程序性能。

我们添加Try-Catch，其实就是为了做异常处理，也就是我们天然的认为被Try-Catch的代码就是会抛出异常的，而异常一旦发生，此时程序性能就会受到一定程度的影响，表现在如下两个方面。

由此可见Try-Catch其实不会影响程序性能，但是异常的出现的的确确会影响，无论是JVM创建的异常，还是我们在代码中new出来的异常，都是会影响性能的。

所以现在我们来看看如下代码有什么可以优化的地方。

public class TryCatchPerformance {



    public Response execute(String state) {

        try {

            return innerHandle(state);

        } catch (Exception e) {

            return new Response(500);

        }

    }



    public Response innerHandle(String state) {

        if (state == null || state.isEmpty()) {

            // 通过异常中断执行

            throw new IllegalStateException();

        } else if ("success".equals(state)) {

            return new Response(200);

        } else {

            return new Response(400);

        }

    }



    public static class Response {

        private int state;



        public Response(int state) {

            this.state = state;

        }



        public int getState() {

            return state;

        }



        public void setState(int state) {

            this.state = state;

        }

    }



}

上述代码的问题出现在innerHandle() ，仗着调用方有Try-Catch做异常处理，就在入参非法时通过创建异常来中断执行，我相信在实际的工程开发中，很多时候大家都是这么干的，因为有统一异常处理，那么通过抛出异常来中断执行并在统一异常处理的地方返回响应，是一件再平常不过的事情了，但是通过前面的分析我们知道，创建异常有性能开销，捕获异常并处理也有性能开销，这些性能开销其实是可以避免的，例如下面这样。

public class TryCatchPerformance {



    public Response execute(String state) {

        try {

            return innerHandle(state);

        } catch (Exception e) {

            return new Response(500);

        }

    }



    public Response innerHandle(String state) {

        if (state == null || state.isEmpty()) {

            // 通过提前返回响应的方式中断执行

            return new Response(500);

        } else if ("success".equals(state)) {

            return new Response(200);

        } else {

            return new Response(400);

        }

    }



    public static class Response {

        private int state;



        public Response(int state) {

            this.state = state;

        }



        public int getState() {

            return state;

        }



        public void setState(int state) {

            this.state = state;

        }

    }



}

如果当某个分支执行到了，我们也确切的知道该分支下的响应是什么，此时直接返回响应，相较于抛出异常后在统一异常处理那里返回响应，性能会更好。

总结

Try-Catch其实不会影响程序性能，因为在没有异常发生时，代码执行链路不会加深。

但是如果出现异常，那么程序性能就会受到影响，表现在如下两个方面。

因此在日常开发中，可以适当增加防御性编程来防止JVM抛出异常，也建议尽量将主动的异常抛出替换为提前返回响应，总之就是尽量减少非必要的异常出现。

也许一切都有个期限。

人生的前 7 年是童年，接着是 17 年的学生生涯（1 年复读)。在大学四年里，除了应付本身的学习外，一半的时间鼓捣音乐，一半的时间在炒股，对结束学生的生活充满了期待。

进入工作以后，来到今年，也17年了。

上班和上学真的很像的。上学时，小学中学大学一路打怪升级，上班时，小厂中厂再到大厂，也是一路打拼。每天两点一线，年复一年，日复一日。

因父亲是国企员工，自小对大厂的集体生活就有恐惧感。然而经过奋斗再进入大厂，享受到更好的福利待遇时，才发现大厂的生活更适合大众。

但是，经过前面几年的折腾，已经消耗过多的精力，进大厂之后缺乏了向前进的动力。在小厂里，你 3-5 年就可以成为小领导。在大厂里，3 年才刚刚对公司各方面有一些了解，才能协调资源去完成一个小项目。大厂里需要消耗更多的时间精力处理本身工作之外的事情。

在大厂时间一天天流逝，发现自己并没有得到真正的提升。

于是，凑巧也是 17 年，终于迎来了结束的一天。

因为给自己打了个 C，喜获炒鱿鱼一份，也正式离开了大部分人走的轨道。

大学的时候无所事事，那四年的确是个人最舒服的时间。现在也无所事事了，挺好。

旅行

没事就找点事吧。除了省内走走逛逛之外，也出省游了。

春天，到武汉赏樱花；秋天，到南京赏枫林。夏天则走了一趟海南环岛游。春夏之间，还去了宁波，与深圳同样的海滨城市。

中国的城市化的确很好，在任何城市生活都不会有很大的差别，只是各处的风景、人文又略有不同。

武汉，赏的是代表着中日友好的樱花，也是它的悠久历史。平原一望无际，楼都比山高，黄鹤楼与长江大桥夹在高楼间，并不显突兀。这里有春秋战国的遗物，有 800 年的楚国文化历史，也有与深圳一样新的光谷。

南京，除了心心念念的红枫林，还有六朝古都的风韵。枫叶看了，南朝四百八十寺看了，再去看看博物馆。作为在文化荒漠长大的广东人，博物馆看到第三天，脑里存储的历史知识已经用完。最后亦不能忘，要去中山陵园瞻仰近代伟人。

宁波像矮版的深圳，高楼大厦少了些，但是不缺发达的城市商业，不缺鲜甜可口的海鲜，也不缺舒适慵懒的海边。这里还有中国最大的私人藏书阁，这里也是徐霞客旅行的起点。

至于海南，熟悉又陌生。的确远离了大陆，除了冼夫人、苏东坡的痕迹外，没有太多先人的故事。在这里躺平也是一个选择。多少明白了全国各地的人都喜欢去海南的原因。

我心中是没游遍全国的计划的。作为一个中年人，开始向内求，其实不太需要外界刺激来放松自己，或者来达到什么样的目的。

明年会不会继续出发？当然是看钱行事。

钱

钱的问题才是主要的问题，尤其对一个失去了工资收入的人。

投资上，今年预判失败，提早清仓了纳斯达克指数 ETF，然后在 9 月底，参与了大 A 股的闪电牛市，但是没有全身而退。在股市上只能说小盈利。离职后，更是忘了“财不入急门”，跑去炒期货，最后在期货上亏了不少。

赢利比最高的反而是虚拟货币。这笔资金来源于参与了新发行的币。卖出后，交易了几笔，账户翻了倍。然而只有可怜的80刀。

所以整体下来，是亏损了。

终于发觉，自己作为 20 年老股民，一直没有很好地对待自己的投资。回想起来，自己有四点没有做好的：

如果有时光机，我一定回去对自己说，“存钱，存钱，存钱！”

技术

今年，对规范、标准有了进一步了解。

在前端里，react 之前在高阶函数、服务端组件中的探索，成就了无头 UI，成就了shacn/ui；shacn/ui 丰富的下游组件、模板成就了 AI 编程工具 v0.dev。目前 v0.dev 还在继续接入 next.js 的模板。

另外，如果用了 RESTful 写的接口，使用 AI 编码可能 1 句话就解决了，如果不是，则需要对增删改查接口，每个都写不同的对话。

可以明确的是，越是标准、规范的技术/项目，越是容易接入 AI。

规范、标准是逐渐形成的，某些技术变成标准的时候，它后续的发展，比其他的技术都要顺利、要迅猛。

像现在国内的手机厂商，都在适配 iPhone 生态一样，即使 iPhone 是封闭的生态，但是其本身有非常丰富的开放的接口，这些接口就是 iPhone 定的标准，一直在稳定逐步推进，一步步地把用户锁在自己的生态中，你不加入永远就分不到蛋糕。（当然，小米也搭建了类似的生态，但影响力仅限国内）

我们在争论标准的时候，从未想过标准背后是什么，从未想过执行标准之后会带来的巨大好处。

国内 SAAS 还在垮台中，他们服务的一家家小公司，甚至是大公司，还在为一个流程要经过谁的审批争得死去活来。外国公司已经完成了阶段的飞跃，他们的数据早已为接入 AI 做好了准备。此时，国内还有些公司想着跳过信息化，直接进入 AI 时代……

说回 AI，如果 2023 是 AI 编程元年，今年就已经有初步成型的产品了，类似于 cursor 之类的编程 IDE。

用了 AI 编程再也回不去了，至少我是这样的。每月的 cursor 的费用并不低，但是它给我带来的收益是远大于此。从写demo，到逐步完成更复杂的内容，我把更多的事情交给了 AI。

总之，拥抱 AI， 依然是这几年的正确选择！

结束语

年底听了李楠在《脑放电波》的访谈，把近几十年关于去中心化的思潮与变革联系起来了。

世界的割裂正在进行，也许回不去那种互助互爱的地球村了，但也回不到联合国与大国控制的世界了。

在去中心化的所有技术都已经突破，成为现实。人们也开始接受虚拟货币，愿意把其变成一份份真的钱在社会上流通。社交媒体上，数字游民满世界的跑，宣扬着这一切的到来。

未来世界，也许真的如其所说，会由一个个的社区组成。你可以成为一个超级个体，社区根据你在链上的贡献给你奖励对应的数字货币，你通过数字货币获取自己所需的商品。

这一切不是不可能。

也许，未来已来！

新的一年继续努力吧，至少，继续为自己努力吧！

许久没扯淡，今天就写点没营养的内容。

前几天和朋友聊天，其中一个话题很有意思，那就是「没用过」和「不知道」是他日常焦虑症的来源，因为他在一家传统企业做开发，技术栈一直很保守，很多框架代码可能一两年都不会升级改动，许多新东西都没用过，所以每次看到别人聊新技术的时候，都会觉得很焦虑，想“了解”却又“用不上”，想“上进”却又“学不进”，最后干脆选择“眼不见为净” 。

其实我过去也有类似的经历，每次接触到“新东西”时，内心潜移默化就会开始着急，仿佛再不跟进就要“挨打”，而“新东西”又层出不穷，结果就是东拼一脚西凑一下，最终像个无头苍蝇一样四处碰壁，不得而终。

为什么你懂这么多？相信这种情况对于「老 Androider 」多多少少应该都经历过，毕竟十年前的 Android 开发，「技术选型」可以说是日新月异，「你用过xxxx吗」和「你还在用xxxx」可以说是圈内话题的主旋律，举亿个例子：

• 你还在用 Eclipse ，现在都用 Android Studio 了


• 你还在本地 jar 包，现在都用 Gradle 远程依赖了


• xUtils 和 Afinal 听说过没？开发神器啊


• 你怎么还在用 ImageLoader ，知道 Picasso 吗？ 用过 Fresco 没有？现在都推荐 Glide 了


• 你知道 GreenDao 吗？现在谷歌都推荐 Room 了，你用过 Realm 吗？


• 你还在用 ButterKnife？现在都用 DataBinding、ViewBinding 了


• 你怎么还用 Apache HttpClient，试试 Volley 呗？


• 现在都是 OKhttp 了，那你知道 Retrofit 吗？


• 你用过 gPRC 和 GraphQL 吗？


• 你还在用 MVC ，你知道 MVP 吗？我都用 MVVM、MVI 了


• 你用过 dynamic-load-apk、VirtualAPK、DroidPlugin、RePlugin、tinker 吗？


• 你知道 Dagger 吗？现在都 Dagger2 了


• 你还在用 Dagger ？ 现在已经是 Hilt 了


• 你用过 EventBus 吗？


• 你知道 LeakCanary 吗？听过 BlockCanary 吗？


• 你还在用 Java 的 Dagger 啊，Kotlin 都用 Koin 了


• 你知道 Rxjava 吗？已经 Rxjava2 了


• 你用过 Couroutines 和 Flow 吗？


• 你知道 LiveData 吗？


• 用过 jadx 和 apktool 吗？


• 怎么还在用 Java ？Kotlin 都烂大街了


• 你知道 Jetpack 吗？用过 Lifecycle、Navigation、CameraX、Paging、Glance、Slice、Startup、Viewpager2、DateStore、WorkManager 吗？


• 你做过小程序吗？uni-app 听过吗？React Native 知道吗？Flutter 、KMP、Compose 了解不？


• 鸿蒙 Next 你适配了没？ArkTS 和 ArkUI 学了没？


• ····

有没有很熟悉的既视感？这还只是 Android 圈子的一角，如果你还做前端：那还有:

jQuery、AngularJS、Angular、Vue、React、Ember、Node、Express、Svelte、Nest、Nuxt、Deno、Solid····

就光说 React 更新带来的 JSX、Portals、Hook、Fiber、Concurrent、Suspense、Server Components、Transitions 就够一直玩下去····

但是在焦虑追新的同时，其实这里面一直有一个问题：会用这些框架，真的就是技术吗 ？你追的究竟是什么 ？

回答这个问题，刚好可以用到最近看到的一张图，因为我们大概率不是一个软件工程师：

• 高情商：蓝领科技者


• 低情商：工厂螺丝工

我们的工作就是使用别人「制作好的工具」，所以我们热衷追逐「新工具」，但是，大多数时候，我们又不了解工具是如何工作的，我们只是一直在“反复”的学会如何使用它们，并且焦虑于，我们还没全都学会。

我认为「拧螺丝」确实是一个很不错的比喻，各类框架就像是适配不同型号的螺丝刀，而市面上的螺丝头形态各异，我们就是不停的在学会「如何把某款型号的螺丝刀插入到对应螺丝头」，然后开始心满意足的拧一颗「新型号螺丝」。

拧熟了，大概还能解锁了多种姿势，拧起来更快更省力，不同型号的螺丝刀，对准的难度和发力的安全范围可能也会有些不同，不过没关系，多拧几次就熟悉了。

那么我们比的是谁认识的螺丝头多吗？

所以，拧螺丝是门槛吗？大概率不是的，因为学会拿螺丝刀就行。那问题又来了，既然都是拧螺丝，换个姿势，换个型号，你就不会拧了吗？不应该啊对吧 ？

回归到各式各样的框架上，有文档和有社区的情况下，换种语言，换种框架，难道就拧不动了？这又扯出另外一个问题：你的能力依赖于框架，是否又能超脱出框架？

所以我们在「追新」的时候追的是什么？是 1 - 2 - 3 这样的变化：

• 从 1 到 2 用户拧螺母需要准备的扳手数量减少了


• 从 2 到 3 扳手变得更加帅气有力，并且附带的“力道”也有所上升

那么开发的鄙视链就来了：

• 因为我用的是自动挡扳手 2 ，所以我看不起手动挡的扳手 1


• 因为我用的是全新工艺的扳手 3 ，所以比老工艺的扳手 2 牛逼

我想着这大概率是「追新」带来的「错觉」，牛逼的是扳手的制造者，而作为使用者，我们都是踩着别人的肩膀混口饭吃的工人。

回过头来看，在这种情况下，随着技术的发展，新生框架和技术会让开发变成更便捷，同时降低开发的门槛，从而方便后来者入坑，所以本质上就像开车，开「自动档」并没有比「手动挡」牛逼多少 。

就算是自动挡，也分很多换挡方式，那么你会用「怀挡」，真的就比用「直排挡」在技术上 NB 吗？难道比的不应该是，谁对「变速箱」的理解更深刻？尽管大部人其实都不会懂得如何造车，但在用车上，大家真正的差距在于：

• 车坏了你会不会修？


• 如何调节提升车的动力和操控

那么回过头来，所以作为老 Android 开发，在经历了开发项目需要准备“一堆扳手”的手动挡时代，如今在这个只要一个“扳手”就能干活的自动挡时代，怎么可能会拧不动螺母？

更多时候问题不在于我们学得不够多，知道的不够新，而是我们不知道框架实际上是如何工作，我们只是学会了使用一个叫做“React”的工具。

不是为了读源码而读源码，而是通过源码我知道了 CVT 和双离合的区别，知道了它们的实现原理和优劣，那么挡把是怀挡还是旋钮重要吗？

在不理解运作的原理，没有基础知识铺垫，当任务变成修理一个发动机时，当任务变成提高框架的性能瓶颈时，就会无从下手，就会回归到前面所说的：You are not a software engineer 。

我们不可能全知全能，也不可能认识所有螺丝头，也没机会熟练操控所有档位型号，但是我们的目的也不是为了认识所有汽车档把，我们的目的只是为了开车，然后进一步能力就是修车和调教，这对于大多数人来说，就很难能可贵了。

大多数人学习精力有限，但是理解能力和开车经验是可以精进的，比如最近看各个大厂的大佬们把 KMP 和 Compose 适配到鸿蒙上的分享，就能感受到老司机们的车技之滑溜。

而回到我们在焦虑「没用过」和「不知道」的时候，更多还是对于自身能力的不自信，就像是我们的尊严只能苟存于框架之下，多年的工作经验，只能寄希望于 XXX 不要凉。

所以才会对于 XXX 要火，XXX 要凉如此敏感，本质还是我们迷失在了工具上。

就像一些多年耕耘的老开发会告诉你，许多上层开发者「跟进」的基本都是：“ keeping up with all the bullshit that Google / Android dev community throws at you” ，远离所谓的 “architecture influencers” ，你需要的是自己的思维方式和选择能力，而不是臣服在框架之下，被社区推来推去：

当前，其实这也和当前很多工作岗位的设定有关系，公司当前只是需要一个螺丝钉，公司不需要你理解螺丝刀为什么十字和一字的区别，你拧就是了，标签化和细分化确实更好管理，而有人也愿意带着标签，这无可厚非。

而大佬们就不同，在和社区大佬的沟通中，我发现基本上他们的涉猎范围都很广泛，而且都很有深度，或者说：语言和框架都只是为了解决问题的工具。

总有人走在你前面，只是你是否还在路上。

好了，其实道理大家都懂，只是如何知行合一，那就见仁见智了，许多没写这种没营养的内容，毕竟纸上得来总觉浅，真要总结，大概就是：人和人体质不同不能一概而论。

大家好，我是一名前端工程师，也是开源图片编辑器vue-fabric-editor项目的作者，2024年5月从北京辞职，我便开始了自己的轻创业之路，接触了不同的客户和业务场景，回顾这半年，没想到学会fabric.js这个Canvas库，竟能做这么多项目。

如果你打算学习一个Canvas库或者做图片设计、定制设计相关的工具，我建议你学习一下fabric.js 这个库，它非常强大，可以做出很多有意思的项目，希望我的项目经历能给你的技术选型做一些参考。

• 开源项目：vue-fabric-editor


• 预览：http://www.kuaitu.cc

项目经历

从北京回老家邯郸后，我陆续做了很多项目，包括正件照设计、锦旗/铭牌定制工具、Shopify定制插件、批量生成图片、手机版图片设计工具、服装设计、电商工具等，这些项目都离不开fabric.js这个库。回顾这段经历，让我深刻体会到它的强大和广泛应用。

图片设计

图片设计是我接触的第一个主要应用领域。项目最初源于一个小红书成语卡片设计工具的构想，随后逐步扩展到更广泛的设计场景，包括小红书封面、公众号头图、营销海报以及电商图片等多种自媒体内容制作。

这类应用的核心功能在于自定义画布尺寸和元素排版，得益于fabric.js的原生支持，实现起来相对简单。我们主要工作是开发直观的属性编辑面板，使用户能够便捷地调整所选元素的文字和图片属性。

当然如果做的完善一些，还需要历史记录、标尺、辅助线对齐、快捷键等，这些功能fabric.js并没有包含，需要我们自己实现，这些功能可以参考vue-fabric-editor 项目，它已经实现了这些功能。

还有很多细节的功能，比如组合保存、字体特效、图层拖拽、图片滤镜等，这些功能我们做的比较完善了。

定制设计工具

图片设计的场景相对通用，没有太多定制化的需求。而定制类的设计工具则需要针对特定场景深度开发，比如正件照、锦旗/铭牌设计、相册设计等，每个场景有不同的定制功能。

正件照设计工具的核心在于自动化的处理。主要工作量集中在尺寸的匹配，确保图片能自动调整到最佳大小。同时，需要提供人物图片的裁剪功能，让用户能便捷地进行换装、切换正件尺寸、更换背景等操作。

锦旗与铭牌设计则更注重文字内容的自动排版。系统需要根据用户输入的抬头、落款、赠言等内容，自动计算最优的文字间距和整体布局，确保作品的美观性。特别是铭牌设计，还需要实现曲线文字功能，让文字能够优雅地沿着弧形排布。

相册设计工具的重点是提供灵活的画布裁剪功能。用户可以使用各种预设的形状模板来裁剪图片，需要确保裁剪后的图片既美观又协调，最终生成精美的画册作品，交互上方便用户拖拽图片快速放入裁剪区域。

电商工具

电商场景比图片设计更垂直，除了普通的平面设计，例如店铺装修、商品主图、详情图的设计，另外还需要对商品进行换尺寸、抠图、换背景、去水印、涂抹消除、超清放大等操作，这些对图片处理的要求更高一些。

批量生成

批量算是一个比较刚需的功能，比如电商的主图，很多需要根据不同产品到图片和价格来批量加边框和文字，以及节庆价格折扣等，来生成商品主图，结合图片和表格可以快速生成，减少设计师的重复工作量。

另一部分是偏打印的场景，比如批量制作一些商品的二维码条形码，用在超市价签、电子价签、一物一码、服装标签等场景，根据数据表格来批量生成。

这种项目主要的工作量在交互上，如何将画布中的文字和图片元素与表格中的数据一一对应，并批量生成，另外会有一些细节，比如条形码的尺寸、图片的尺寸如何与画布中的尺寸比例进行匹配，这些细节需要我们自己实现。

上边的方式是通过表格来批量生成图片，还有一种是根据 API来批量生成图片，很多场景其实没有编辑页面，只希望能够通过一个 API，传入模板和数据，直接生成图片，fabric.js 支持在nodejs 中使用，我们要做的就是根据模板和数据拼接 JSON，然后通过fabric.js 在后端生成图片，然后返回给前端，性能很好，实际测试 2 核 2G 的机器，每张图片在 100ms 左右。

很多营销内容和知识卡片、证书、奖状也可以通过批量生成图片API来实现。

当然，还有一些更复杂的场景，比如不同的数据匹配不同的模板，不同的组件展示不同的形式等，包括错别字检测、翻译等，我们也为客户做了很多定制化的匹配规则。

服装/商品定制

服装/商品定制是让用户在设计平台上上传图片，然后将图片贴图到对应的商品模板上，实现让用户快速预览设计效果的需求。

这种场景一般会分为 2 类，一类是是针对 C 端用户，需要的是简单、直观，能够让用户上传一张图片，简单调整一下位置就能确认效果快速下单。

我在这篇文章里做了详细介绍：《fabric.js 实现服装/商品定制预览效果》。

另一类是针对小 B 端的用户，他们对设计细节有更高的要求，比如领子、口袋、袖子等，不同的位置进行不同的元素贴图，最后将这些元素组合成一个完整的服装效果图，最后需要生成预览图片，在电商平台售卖，完成设计后，还要将不同区域的图片进行存储，提供给生产厂家，厂家快速进行生产。

比如抱枕、手机壳、T恤、卫衣、帽子、鞋子、包包等，都可以通过类似服装设计的功能来实现。

很多开发者会提出疑问，是否需要介入 3D 的开发呢？
我们也和很多客户沟通过，从业务的角度看，他回答是：3D 的运营成本太高。他们做的都是小商品，SKU 很多很杂，如果每上一个商品就要进行 3D 建模，周期长并且成本高，他们更希望的是通过 2D 的图片来实现，而且 2D 完全能够满足让用户快速预览确认效果的需求，所以 2D 的服装设计工具就成为了他们的首选。

包装设计

包装设计是让用户在设计平台上，上传自己的图片，然后将图片贴图都包装模板上，主要的场景是生成定制场景，比如纸箱、纸袋、纸盒、纸杯、纸质包装等，这些场景需要根据不同的尺寸、形状、材质、颜色等进行定制化设计，最后生成预览图片。

因为设计到不同的形状和切面，而且大部分是大批量定制生产，所以对细节比较谨慎，另外包装规格相对比较固定，所有用3D模型来实现就比较符合。

另外，在确定设计效果后，需要导出刀版图，提供给生产厂家，厂家根据刀版图进行生产，所以需要将设计图导出为刀版图，这个功能 fabric.js 也支持，可以导出为 SVG 格式直接生产使用。

AI结合

在AI 大火的阶段，就不得不提 AI 的场景了，无论在自媒体内容、电商、商品、服装设计的场景，都有 AI 介入的影子，举个例子，通过 AI生成内容来批量生成营销内容图片，通过 AI 来对电商图片进行换背景和图片翻译，通过 AI 生成印花图案来制作服装，通过 AI 来生成纹理图来生成纸盒包装，太多太多的 AI 的应用场景，也是客户真金白银定制开发的功能。

展望2025

从图片设计的场景来看，我们的产品已经很成熟了，也算是主力产品了，未来会持续迭代和优化，让体验更好，功能更强大，把细节做的更完善，例如支持打印、视频生成等功能。

从定制设计工具的场景来看，我们积累了不同商品定制设计的经验，从技术和产品到角度看，我们还可以抽象出更好的解决方案，让客户能够更高效、低成本的接入，提供给他们的客户使用，快速实现设计生产的打通。

2024 到 2025 ，从在家办公一个人轻创业，搬到了我们的办公室，期待未来越来创造更多价值。

总结

半年的时间，这些项目的需求fabric.js都帮我们实现了，所以如果你对Canvas感兴趣，我的亲身经历告诉你，学习fabric.js是一个不错的选择。

另外，对我来说更重要的是，客户教会了我们很多业务知识，这些才是宝贵的业务知识和行业经验，一定要心存敬畏，保持空杯，只有这样我们才能做好在线设计工具解决方案。

这篇文章也算是我从 2024年离职出来到现在的一个年终总结了，希望我们踩过的坑和积累的经验都变成有价值的服务，作为基石在2025年服务更多客户，文章内容供大家一些参考，期待你的批评指正，一起成长，祝大家 2025年大展宏图。

给我们的开源项目一个Star吧：github.com/ikuaitu/vue… 😄。

罗永浩备受期待的AI应用——J1 Assistant终于上线了，这款应用标志着他“最后一次创业”的正式启动。曾因锤子手机与SmartisanOS而广受关注的罗永浩，在经历过硬件领域的沉浮后，终于转向了AI技术的蓝海。J1 Assistant的上线，成为了他在AI领域的新起点，而这款产品也标志着罗永浩的“真还传”之路的回归。

目前，J1 Assistant已在Android平台推出Beta版，但只有三星Galaxy和谷歌Pixel的最新三代机型支持，且仅提供英文版，显然其首要市场定为海外而非国内。这一策略也印证了罗永浩的新目标——跨越国界，将AI技术推向全球。

与此同时，罗永浩的另一款 AI 硬件新品——JARVIS ONE也在路上，官网已有预告，预计将参加即将举行的CES 2025消费电子展。

请在此添加图片描述

锤子味的AI助手：重回初心，旧貌换新颜

从产品的设计来看，J1 Assistant显然延续了“锤子味”，无论是UI设计还是功能整合，都能看到过去SmartisanOS的影子。这款应用不仅仅是一个普通的AI助手，它可以视作待办清单、便签、AI聊天、即时通讯、搜索等多种功能的集合体。对于曾经使用过锤子手机的用户来说，这些熟悉的设计元素不仅带来了一种情感上的回归，也让人感受到一种怀旧的力量。

J1 Assistant通过五个Tab区分了五大核心功能：To Do（待办清单）、Notes（笔记）、AI Assistant（助手）、J1 Message（聊天）和Search（搜索） 。其中，Notes的设计延续了锤子便签的风格，但功能上略显简陋，缺乏排版工具和图片分享功能；To Do则是一个基础版待办清单，操作简便，却略显单一。

请在此添加图片描述

AI与信息管理的双重打击：技术与实用的结合

与传统的待办清单和笔记功能相比，J1 Assistant还融入了更多创新性功能——J1 Message和Search。J1 Message的设计灵感来源于已停运的“子弹短信”，用户通过注册后可进行即时聊天，然而在如今的即时通讯市场竞争如此激烈的情况下，这一功能能否得到用户的广泛接受仍有待观察。而Search功能，则类似于TNT的“发牌手”，支持多来源的搜索，用户可以根据自己的需求自定义最多五个来源进行查询。

在语音交互方面，J1 Assistant也做了突破，采用了“Ripple Touch（波纹触摸）”设计，用户按住语音图标进行语音输入时，可以灵活选择不同的操作方式（如保存为笔记、待办清单或直接发送给他人），这无疑增加了操作的便捷性和实用性。

请在此添加图片描述

AI价值的延伸：效率与便捷并重

J1 Assistant的最大亮点，不仅仅是传统的AI对话功能，而是它如何巧妙地将AI与信息管理结合，创造多重价值转化。举个例子，用户可以要求AI将它的回答直接保存为待办清单或笔记，从而将信息的价值最大化。如果你在CES 2025期间，想要记录重要的展会活动，AI助手就能帮助你快速整理信息，自动生成待办清单和笔记，从而大大提升工作效率。

尽管目前J1 Assistant还处于Beta版本，存在一些问题和bug，比如部分AI回答保存不完整，或者待办清单内容丢失等，但这些问题在更新后有望得到解决。正如任何一款刚上线的产品一样，J1 Assistant的潜力还有待发掘。

定位问题：这款APP真的能满足我们需求吗？

虽然J1 Assistant融合了多个创新功能，但它的市场定位仍显模糊。与其他成熟的AI助手相比，J1 Assistant的功能整合显得有些“乱炖”，缺乏独特的亮点和清晰的市场定位。尤其是在待办清单和笔记功能这一块，它是否能够真正吸引到那些有强烈需求的用户，仍然是一个未知数。

罗永浩的AI之路，还能走多远？

请在此添加图片描述

J1 Assistant是罗永浩进入AI领域的第一步，但要想在竞争激烈的市场中脱颖而出，它仍面临不小的挑战。从目前来看，J1 Assistant确实有着不少创新之处，尤其是在信息管理和AI对话的结合方面，但它能否真正解决用户的痛点，还需更多时间的验证。罗永浩的“真还传”之路，依然充满变数，他的AI应用能否走得更远，或许最终取决于它是否能够精准满足用户的实际需求，带来真正的价值。

从硬件到软件，罗永浩的创业之路仿佛进入了一个全新的阶段。这一次，他的“AI助手”会带给我们什么样的惊喜，值得每个人期待。

前支付宝工程师带你复盘支付宝P0故障

事故介绍

首先叠个甲，所有数据来自互联网公开数据，没有泄露任何老东家数据。

大家可能都听说了，但是我还是介绍一下。2025-1-16 14:40开始，一部分用户发现在支付宝内进行支付时，发现订单被优惠减免了20%的金额。意味着原本你买一个手抓饼可能100块，用支付宝直接省20。而且这不仅限于支付订单，转账订单也可以享受这个优惠(不知道有没有人开两个小号，反复转账薅羊毛的)。

支付宝方面很快反应，在14:45时完成了故障修复，并且在2025-1-17 1:00发出声明，称不会对享受到这个优惠的用户追回资金。(敢做敢认，点赞)

产生原因分析

在支付宝的通告里，我们看到，产生这个事故的原因是"某个常规营销活动后台配错了营模板"，这句话我给大家解释一下。一般一个新的活动功能的上线，可能需要程序员开发新的功能，然后将功能里需要使用的规则，做成配置，配置在营销中心的管理后台上。当然对于一些比较成熟的活动，也可以直接复用以前的代码，只需增加配置即可。

但是在通告里，我们没办法判断这是一个新开发的活动还是复用以前开发出的老活动。针对需要开发的新活动和可以直接使用配置复用的老活动，这两者我们单独分析。

需要开发的新活动

一般新活动开发完毕后，正常是程序员会提前告诉运营在配置中心建好规则，并且将灰度人群置为0。然后程序员发布新代码，发布中因为没有人群命中活动规则，所以活动不生效。为了验证代码有效，会在发布的早期，让运营在营销中心配置一些测试用户，来测试看能否命中规则，并且验证活动在后续的收单，结算流程里是否正常。

举一个实际的例子，程序员小薰在服务demo order service里开发了新功能，需要发布上线，demo order service假设有1000台机器，小薰联系运营小丽在运营中心配置几个灰度账号，用来验证在线上发布后功能是否正常。在灰度发布阶段，会先选择几台机器做灰度，一般不超过10台，比如

• 第一批次 3台


• 第二批次 7台


• 第三批次 5%


• 第四批次 10%


• 第五批次 20%


• 第六批次 35%


• 第七批次 全量发布剩下所有的机器

根据支付宝解决故障只花了5分钟，我们可以推测出，应该是在第一批次时就发现了问题，并且采取了止血措施。那么收到影响的流量就是0.3%-1%，大家可能好奇为什么能确定说肯定是在第一批次就收到的影响，因为实际一次服务重启很耗时，一般都不止5min，而且服务发布后会有10-30min的观察期，再结合发生事故到解决事故总共没花费5min，我们可以推测出，第二批次应该还没发布。

但是流量并不代表受到影响的支付单量，因为要考虑有多少人命中了这个规则，这就取决于运营的配置了，如果运营只是把一些不应该开灰的用户加在了白名单里，影响还好，只会有一些固定的人员受影响。但如果运营是直接100%用户全量灰度，那就糟糕了。

我们得出在这种情况下，受到影响的单量范围为(0, 1%)

亏了多少钱

相信大家最感兴趣的一定是这次事故支付宝到底亏了多少钱，要回答这个问题我们首先要知道支付宝一天的交易流水是多少。当然这种数据官方一般是不会放出来的。但是我们可以大概算一下

23年移动支付555万亿，增速为11%。我们假设还是按照这个增速来预测24年的移动支付，当然还要考虑支付宝和微信在移动支付交易市场的份额，大概6/4开的比例。

那么24年的移动支付交易额

#以下单位亿元

5550000 * 1.11 = 6160500

#那么24年的平均日交易额

6160500/365 = 16878.08

#考虑到昨天事故发生的时间已经是25年，我们直接用24年的平均日支付交易额不合适，我们假设移动支付的日交易流水增长是线性的，我们再乘以一个增长速率得到12月的移动支付日交易额

16878.08 * 1.22 = 20561.26

#再乘以支付宝再移动支付市场的份额

20561.26 * 0.6 = 12336.76

那么我们假设支付宝一天的交易金额12336.76亿元，那么结合我们预估的影响流量范围(0, 1%)，以及每一单20%的优惠力度，影响的时间5min，得出在事故事件内受影响的订单数量

# 单位亿元

12336.76 * 0.01 * 0.2 * 5 / 60 / 24 = 0.0857 

即亏损金额不超过857W，实际上考虑到这种带有优惠的活动可能会有用户薅羊毛，重复下单，我们可以再把它影响范围乘以一个放大系数，比如1.5，即

#单位万元

857 * 1.5 = 1286

可以看到金额顶天也不会超过1286W，而且在实际的营销活动里配置的时候，一个营销活动的预算金额是会有上限的我们称为资金池，超过这个上限即使参加活动也不能享受到优惠，这个金额我们假设为2000W(一般活动不会这么多，一般几百万就算多了)。如果资金池小于1286W，比如资金池只有500W，资损的上限就只有500W了。

总的来说，我们还是认为本次事故的资损对于支付宝来说并不算多，大概1286W。

那些人会背锅

大家第二感兴趣的肯定就是那些人会背锅了，我们可以从整个流程上看那些人参与了这次事故。

• 运营 作为直接引发本次事故的责任人，没有认真检查配置，就上线，肯定要背大锅，主要责任跑不掉。(考虑到蚂蚁最近的降本增效，不知道这位运营是不是本部的也说不准)


• 开发功能的程序员 开发功能的程序员负责上线服务，并且把配置设计好交给运营人员去配置，虽然不是程序员配的，但是作为服务的owner，理论上应该要再发布前再去确认一下这个配置正不正确,所以开发跑不了(是不是感觉pua太凶了，放心吧，实际老板找你北固时说辞肯定比这更严重)


• 运营的老板，以及审核了运营配置的老板 所有配置都需要老板审核才能生效的，虽然老板一般不细看，但是不出事都好，出了事，背锅吧。


• 测试 测试老实说，责任不大，一般这种时候就是拉出来做替罪羊，和开发一样要带点连带责任。


• 程序员的老板 老板这种时候就还是连带责任


• 两位老板的顶头上司 这种级别的老板一般就是P9/P10了，分团队。责任大小也看事故的影响面，影响不大的话，处分大概就是罚酒三杯，大的话，被一撸到底边缘化也有可能

不需要开发的老活动

如果是不需要开发的老活动，运营直接在运营中心改配置即可让活动生效，这种情况下受到影响的流量范围就取决于运营的操作了，(0,100%]都有可能

亏了多少钱

这种情况下资损的计算方式还是类似上面，只不过在流量的影响范围变大了，我们可以直接用上面计算出的亏损金额乘以流量的影响倍率

#单位万元

1286 * 100 = 128600

看起来好像很夸张128600，以下干到13Y了，但是还是像我们上面说的，资损不会超过资金池配额，我们假设的资金池配额5000W，所以其实还好。实际的资金池配额我想会远远低于这个数。

那些人会背锅

• 运营


• 运营的老板


• 运营的老板的老板

背锅原因同上，不细说了

事故总结

从这次的事故，我们可以复盘一下再新功能上线时需要面临哪些问题以及对应的解决思路。当然支付宝内部也都有这些手段的成熟解决方案，但是实际落在执行上却是稀巴烂。

生活

年初，在老家办了答谢宴，也算是完成了父母的心愿，他们总说着等我结婚了，他们就可以退休了，虽然没有挣到钱，买的那个社保也领不了多少钱。但想到他们马上60了，人生难道就是打一辈子工吗？我支持他们回老家，无论怎样，有钱多花点，没钱少花点。

5.1 去了抚仙湖，昆明，抚仙湖之前去过一次，这次换了个位置，找了个山上的民宿，自由风还是很舒服。

现在想想，跳龙门，我是不是应该从上面翻过去，哈哈哈哈😂！！！！

7月份暑假期间，又去了一次三亚，住了一次海景房，贵的确实有道理。这次6个小伙伴一起，租了一辆车，沿着海南的东线，从三亚自驾到海口，第一次知道海南的高速不收费。

8月份去了贵州，赤水瀑布，赤水瀑布有充电桩，进去游玩的时间正好充电，算是第一次自驾游吧(海南算租车游😂)；

当时，出去游玩全是大妈大爷，好羡慕他们呀，想原地退休！

去看了草原，和我想象的不一样，我一直以为草原就是公园的放大版，还是我见识少了，去了六盘水是真的凉快。

8月底，我老婆怀孕了，也是在5.1 开始备孕的，本来想的是到8月再怀不上，就等明年了，相当于我们在他不到一个月的时候，就带他去自驾游了，也是心大。

国庆节，因为怀孕，就没出远门，我自己回了趟老家，然后去定了月子中心，老婆结婚那会儿就说一定要住月子中心。知道怀孕后，就是产检，但基本都约的周内，我没有去，丈母娘陪着去的。
月子中心提供了孕期瑜伽，我还陪着她去参加了两次双人瑜伽。

12.22号去看了四维，有了他的第一张照片，也开始焦虑，该怎么教育小孩，都是全新的体验。期待着他的到来...

自媒体

技术方面，已经算是停止输出了。

今年尝试了很多小红书账号，我原本做苔藓的账号，靠ai生成的图，涨了几千粉，但没找到变现的路子，然后停了。

前端的账号，无意中接了一个面试招人的单子，挣了2000。然后觉得前端已死，技术方面不想做了，就注销了账号。

陆陆续续做了ai 壁纸，自媒体方面的，还找了一个做项目的人，花了300块钱，但是后面我也没做起来。12月份去考了普通话，我小学教资笔试面试都过了，就等普通话二甲，就可以领证了。然后就自己做了个普通话学习助手，又在小红书做起了，普通话赛道。
http://47.109.182.55/

对了，母婴赛道也起了个账号，现在主要都在记录一些孕期日常，看看后面小孩出生有没有什么可做的选题吧。

今天自媒体账号真的做了好多，肯定不少于6个。

还有抖音，也搬运了一些视频，没什么好的点子，算了吧。

前端&工作

还记得，当年刚入行的时候，写的第一篇文章《从学校到实习直至毕业，前端——我一直在路上》，还想着老了来回味，哈哈哈，感觉我的职业生涯也走到了末期了！！

因为我已经不看好做技术了，就业形势艰难，我的群里，今年失业的好多，还有人被裁了两三次，工资一降再降，都还是要干。也有认识的大学生，毕业了一直找不到工作，特别是双非大学生，马上过完年，新一批的大学生又要出来了，哎...

我也停止了在技术上进一步深耕，一直都在尝试自媒体，其他的实体创业也不敢辞职去干。
工作上呢，在这个公司快两年了，也没有做出什么成功的产品，我对公司的方法论也不认可了，一句话在这行疲了 —— 巨轮难掉头！

今年的精力大多花在了自媒体上，技术方面没学什么东西，公司今年新项目又用上了nextjs，现在我们是vue3, react, nextjs, nuxtjs 并行，好几个项目同时在做，感觉就技术来说，公司领导想要啥就用啥呗。

而且我们都用上了cursor，ai的发展让我更焦虑了，在ai的时代，我们应该扮演什么样的角色。首先我也认同ai不可能取代所有的程序员，但它提高了生产效率的同时，必然就用不了那么多人了。我之前看到一句话：“不要和ai比智力，不要和机器人比体力”,我很认同，有了cursor，我的工作变得更简单了，更快捷了。我也不觉得，我们再去学什么技术栈，能比他更快，特别是工作过几年的同学，语言都是相通的，有了ai的加持，切换技术栈就像喝水一样，可能有点夸张，但门槛已经很低了。

上面的普通话助手，我就是让cursor写的，我主要提供一下数据，做一些微调，我觉得它真的挺不错的，当然它就是不能背锅!😂

前端，我可能不能一直在路上了，对不起，我明年还得大力尝试做其他的突破，寻找下一个方向。

最后

各位，不破不立，愿新的一年，万事顺心！！！！

Timesheet.js - 轻松打造炫酷时间表

前言

在现代网页设计中，时间表是一个常见的元素，用于展示项目进度、历史事件、个人经历等信息。

然而，创建一个既美观又功能强大的时间表并非易事。

幸运的是，Timesheet.js 这款神奇的 JavaScript 开源时间表库为我们提供了一个简洁而强大的解决方案。

本文将详细介绍 Timesheet.js 的特点、使用方法，并通过一个真实的使用案例来展示其强大功能。

介绍

Timesheet.js 是一个轻量级的 JavaScript 库，专门用于创建基于 HTML5 和 CSS3 的时间表。

它无需依赖任何外部框架，如 jQuery 或 Angular.js，即可快速生成美观的时间表布局。

Timesheet.js 的优势在于其简洁性和用户友好性，仅需几行 JavaScript 代码即可实现功能，同时提供了丰富的自定义选项，允许开发者根据需求进行样式调整。

核心特性

无依赖：不依赖任何外部 JavaScript 框架，减少了项目复杂性和加载时间。
易于使用：通过简单的 JavaScript 代码即可创建时间表，易于上手。
高度可定制：提供了丰富的 CSS 类，方便开发者自定义时间表的外观。
响应式设计：支持移动设备，确保在不同屏幕尺寸上都能良好显示。

官方资源

官网：sbstjn.github.io/timesheet.j…

GitHub 仓库：github.com/sbstjn/time…

使用案例

假设我们要为一个在线教育平台创建一个展示学生学习历程的时间表。

这个时间表将展示学生从入学到毕业的各个阶段，包括参加的课程、获得的证书等信息。

步骤 1：引入库文件

首先，在 HTML 文件中引入 Timesheet.js 的 CSS 和 JavaScript 文件。

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/timesheet.js/dist/timesheet.min.css" />

<div id="student-timeline">div>

<script src="https://cdn.jsdelivr.net/npm/timesheet.js/dist/timesheet.min.js">script>

步骤 2：准备数据

接下来，准备时间表所需的数据。

在这个案例中，我们将展示一个学生从 2018 年入学到 2022 年毕业的学习历程。

const studentTimelineData = [

  ['09/2018', '06/2019', '入学 & 基础课程学习', 'default'],

  ['09/2019', '06/2020', '专业课程学习', 'ipsum'],

  ['07/2020', '01/2021', '暑期实习', 'dolor'],

  ['09/2020', '06/2021', '高级课程学习', 'lorem'],

  ['07/2021', '01/2022', '毕业设计', 'default'],

  ['06/2022', '09/2022', '毕业 & 就业', 'ipsum']

];

步骤 3：初始化 Timesheet.js

最后，使用 Timesheet.js 初始化时间表，并传入准备好的数据。

完整代码

将上述代码整合到一个 HTML 文件中，即可创建出一个展示学生学习历程的时间表。

html>

<html lang="en">

<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>学生学习历程时间表title>

  <link rel="stylesheet" href="./timesheet.js/dist/timesheet.min.css" />

head>

<body>

  <div id="student-timeline">div>

  <script src="./timesheet.js/dist/timesheet.min.js">script>

  <script>

    const studentTimelineData = [

      ['09/2018', '06/2019', '入学 & 基础课程学习', 'default'],

      ['09/2019', '06/2020', '专业课程学习', 'ipsum'],

      ['07/2020', '01/2021', '暑期实习', 'dolor'],

      ['09/2020', '06/2021', '高级课程学习', 'lorem'],

      ['07/2021', '01/2022', '毕业设计', 'default'],

      ['06/2022', '09/2022', '毕业 & 就业', 'ipsum']

    ];

    const timesheet = new Timesheet('student-timeline', 2018, 2022, studentTimelineData);

  script>

body>

html>

效果如下

总结

Timesheet.js 是一个非常实用的 JavaScript 时间表库，它以简洁的代码和强大的功能为开发者提供了一个创建时间表的便捷工具。

通过本文的介绍和使用案例，相信你已经对 Timesheet.js 有了基础的了解。

无论是在个人项目还是企业应用中，Timesheet.js 都能帮助你快速创建出美观且功能强大的时间表，提升用户体验。

如果你对 Timesheet.js 感兴趣，不妨尝试在自己的项目中使用它，探索更多可能。

前言

最近公司项目有时需要和多个后端同时对接（😔小公司一对N），于是对公司项目基础配置文件做了些修改，最终达到能对于多个后端同时启动多个前端服务，而不是每次都需要和A同学对接完，代理地址再换成B同学然后重新启动项目

个人经验0.5年，菜鸡前端一枚，第一次写文章，只是对个人工作简要记录😂!!!

公司项目有vue脚手架搭建的也有vite搭建的，下面让我们分两种方式来修改配置文件

vue-cli方式【webpack】

1. 个人习惯把proxy单独抽离出来放到.env.development

# 启动端口号

VUE_PORT = 8000



# 代理配置

# A同学

VUE_PROXY_A = [["/api","http://localhost:3001"]]



# B同学

VUE_PROXY_B = [["/api","http://localhost:3002"]]

2. 使用cross-env来加载不同的代理

npm i -D cross-env

重新编写下script

3. 读取环境变量

vueCli内部dotenv已经加载到process.env,我们再做一层包裹，之前配置的proxy，这种其实是字符串，需要处理

const { VUE_PROXY, VUE_PORT } = require("./constant.js")



// Read all environment variable configuration files to process.env

function wrapperEnv(envConf) {

  const ret = {}

  const SERVER_NAME = process.env.NODE_ENV_PROXY || VUE_PROXY



  for (const envName of Object.keys(envConf)) {

    if (!envName.startsWith('VUE')) {

      continue

    }

    let realName = envConf[envName].replace(/\\n/g, '\n')

    realName = realName === 'true' ? true : realName === 'false' ? false : realName



    if (envName === VUE_PORT) {

      realName = Number(realName)

    }

    if (envName === SERVER_NAME && realName) {

      try {

        realName = JSON.parse(realName.replace(/'/g, '"'))

      } catch (error) {

        realName = ''

      }

    }

    ret[envName === SERVER_NAME ? VUE_PROXY : envName] = realName

    if (typeof realName === 'string') {

      process.env[envName] = realName

    } else if (typeof realName === 'object') {

      process.env[envName] = JSON.stringify(realName)

    }

  }

  return ret

}



module.exports = {

  wrapperEnv

}

这样我们就可以拿到所有的环境变量，并且proxy是数组，而不是字符串

4. 生成proxy

/**

 * Used to parse the .env.development proxy configuration

 */



const httpsRE = /^https:\/\//



/**

 * Generate proxy

 * @param list

 */

function createProxy(list = []) {

  const ret = {}

  for (const [prefix, target] of list) {

    const isHttps = httpsRE.test(target)



    // https://webpack.docschina.org/configuration/dev-server/#devserverproxy

    ret[prefix] = {

      target: target,

      changeOrigin: true,

      ws: true,

      pathRewrite: { [`^${prefix}`]: '' },

      // https is require secure=false

      ...(isHttps ? { secure: false } : {}),

    }

  }

  return ret

}



module.exports = {

  createProxy,

}

5. 修改vue.config.js

const { defineConfig } = require('@vue/cli-service')

const { wrapperEnv } = require('build/vue/util')

const { createProxy } = require('./build/vue/proxy')



const {

  VUE_PORT,

  VUE_PROXY

} = wrapperEnv(process.env)



module.exports = defineConfig({

  transpileDependencies: true,

  // webpack-dev-server 相关配置

  devServer: {

    host: '0.0.0.0',

    port: VUE_PORT,

    open: false,

    overlay: {

      logging: 'info',

      errors: true,

      warnings: true

    },

    proxy: createProxy(VUE_PROXY),

    disableHostCheck: true

  },

})

6. 使用mock模拟两个后端服务

A同学使用3001端口
B同学使用3002端口

7. 测试是否达到效果

同样我们前端也起两个8000和8001

接下来看下8000端口请求

再看下8001请求

vite

结语

以上只写了webpack不过vite和这也差不多！！！

差点翻车

前两个月的某天凌晨，我司全新的一个营销工具，在全国如期上线。然而整个发布过程并非一帆风顺，在线上环境全量发布后，有同事观测到他所负责模块的监控曲线有异常！监控曲线在发布的时刻近乎于直线下跌。

经过初步排查，故障影响是：一部分新用户无法使用营销优惠~ 影响面非常大，所幸在凌晨的业务低峰期，实际影响有限，但是需要快速修复！不然等天亮用户请求量上来了，故障影响和定级就更大了！

目前接近凌晨4 点，时间很紧张！虽然这部分内容并非我负责，但我是当天的现场值班人，必须上！肝！

屎海无涯

我喝了一口红牛，打开电脑就扎进了陌生代码的汪洋大海中……

看着看着，我察觉到味道不对劲。我觉得这部分代码不是汪洋大海，而是一片屎海…… 代码堆砌如屎山，单个方法竟超过500行；嵌套的if else结构深不可测；日志更是完全缺失；职责不但不单一，反而极度混乱。总之，整个代码简直如同一团乱麻，排查难度极大。

四五个同事一起在排查代码，虽然他们负责过这部分代码，但是大家都十分挠头，找不到 bug 在哪。

当局者迷，旁观者清。经过了30分钟的细致分析，终于，我率先找到了 bug 原因。激动地心颤抖的手，我开了 5 分钟的 bug 发布会，通报了 bug 根因和修复方案。

破案了！

确定 bug 根因后，其他人默默去休息了……

接下来我负责修 bug、测试、打包、发版、验证…… 不知不觉，天空破晓，一直搞到早上 8 点多…… 在线上完成验证，监控曲线恢复正常！bug 修复完成！

bug根因

由于公司代码保密，所以我使用伪代码解释。

业务逻辑是遍历所有的优惠活动，若任意一个优惠活动需要限制新用户使用，那么就需要去查询当前用户是否新用户。

bug 代码如下！ （实际的屎山代码，比这部分代码要复杂得多！）

boolean newUserCheckEnabled = false;

for ( Activity activity : activityList ) {

     newUserCheckEnabled = activity.isLimitNewUser();

}

想必大家一眼就能看出问题所在！这样写代码， newUserCheckEnabled 等于最后一个活动的值，如果最后一个活动不限制新用户使用，那么 newUserCheckEnabled 就是 false，然而中间的活动可能需要限制新用户，于是 bug 产生了！

老板亲自指导写代码

正确的代码应该这样写，我按照如下方式修复了 bug，但是老板对代码不满意！

boolean newUserCheckEnabled = false;

for ( Activity activity : activityList ) {

     if (activity.isLimitNewUser()) {

         newUserCheckEnabled = true;

     }

}

”一行代码就能解决的事，不需要使用 if “ ，老板看完我的代码后，说道。

他给出的代码示例如下，使用 || 表达式

boolean newUserCheckEnabled = false;

for ( Activity activity : activityList ) {

     newUserCheckEnabled = newUserCheckEnabled || activity.isLimitNewUser();

}

if 代码被替换如下！

newUserCheckEnabled = newUserCheckEnabled || activity.isLimitNewUser();

"这能行吗”？ 我的大脑飞速运转…… 这两段代码等价吗？似乎等价，但不是十分确定……

老板面前，不能暴露自己没跟上节奏，否则暴露智商。

我假装立刻明白，于是吹了一句，“卧槽，牛逼，这样写确实更加简洁吖！👍🏻”。（大家觉得应该怎么拍马屁，更合适？）

私底下，我还在心里嘀咕，两者真的等价吗？

现在我可以肯定：确实是等价的！

我以残躯入2025-以身入局胜天半子

今天是 2025 年的第二天，我写下这篇文章，讲述我在 2024 年的经历和挑战，以及我如何克服困难，最终成功走出困境。本来是想昨天元旦第一天写的，但不凑巧的是元旦第一天我得甲流了，发烧了一天，所以今天才写这篇文章。

回顾2024

2024 年可以说是我经历的一个不平凡的一年，经历了股票亏损、事业不顺、年底被裁员、元旦得了甲流等诸多困难。

股票投资

我在 A 股其实也算一个老手了，虽然挣的少，但前 5 年基本上都是挣的，但比较悲催的是 24 年证券主席换了之后，市场行情波动极大。

先是我买的业绩不错的成长股持续下跌，后面换仓重仓买了国资背景的通信行业股票，想着上涨趋势但没想到 5 月直接 ST 了，直接导致了我今年股票大幅度下跌，最多时亏损达 50%+。

同时也买了港股，港股也被踢出港深股通了，股价至今还跌幅超过 80%，基本上就是把我本金吃掉了。

因为股票跌幅比较大，每个交易日对我来说，都是折磨啊，我也很无奈。越追越跌、不追继续套牢，这种情况到 24 年 9 月才有一定的缓解。

事业不顺

23 年下半年，我手底下的俩个前端小伙伴被裁员了，导致从 23 年底到 24 年都非常的忙，被压的闯不过气来，也萌生了跳槽换个新的工作环境的想法，也出去找了工作，但一直找不到合适的工作，都要求降薪，那我就不能接受了。

然后，公司 9 月份搬家，我通勤时间增加了 20 分钟，每天来回就是 40 分钟，接近每天快 3 小时的通勤时间，然后公司还要求我们免费加班到 8 点，目前还在执行这个政策中，即晚 8 点才能下班，8 点之后才算加班调休，这点让我很头疼。

年底被裁员

到了年底 11 月公司开启了我入职以来的第三波裁员，这次的主题是降本增效，在 11 月我们小部门裁掉了一个 BI（我们薪资最高的）、一个测试、产品、还给我们后端 JAVA 薪资最高的同学来了个降薪 3.5K，据说我也在裁员名单上，我的薪资其实蛮高的，后来的开发基本上都比我低，但 11 月我没有收到对我裁员或降薪的通知，以为躲过了一次。

但到了 12 月上旬，有一天 CTO 让我晚点留下给我讲了合同到期不续的事情，至此我被正式裁员了，但因为提前一个月通知的，只给我赔偿 n，同时也不给我年终奖，前俩年我的年终奖其实挺高的，都是 3.5+ 的评分，有 2 个月。

虽然被裁了，但我也没有啥不开心的，因为公司的工作环境已经极度恶化了，年终下调、裁员、降薪、加班、同事内卷，已经不是我愿意为之付出努力的公司了。

元旦甲流

以为就这样熬过了 24 年，但危险悄然而至，12 月 31 号晚上，我开始发高烧，我的儿子从 30 号就开始高烧不退了，最后在元旦那天去医院确诊了甲流，也算是一个悲剧的开年，只能看着别人去逛商场跨年。

这也让我认识到身体健康其实是第一位的，其他都是其次。

走出困境

在投资方面，虽然目前我还是亏损的，但我有信心在 25 年收益回正，这一年的大幅下跌和波动，让我对如何研究股票和人性有了更深的体会，目前已经从亏损的 50% 回到了 20%，也让我有了更多的经历。

事业方面，年中开始我积极调整自己的个人状态，已经找回初心，开始了新的工作状态：积极写博客记录学习状态、持续进行技术分享、参加社区活动、积极的找新工作。通过持续的沉淀和学习，我逐渐找到了自己的兴趣和方向，那就是未来朝独立开发者的道路走，未来我可能是个销售、运营、产品、项目经理，但也会持续的进行产品开发，通过技术造福大众。

学习方面，我持续写了一些系列，大约有 60 多篇文章，也希望和大家一起学习，一起进步成长。

• 《前端学习专栏》


• 《前端框架专栏》


• 《好书阅读专栏》


• 《服务端学习专栏》


• 《算法学习专栏》


• 《NodeJS和NestJS学习专栏》


• 《Python学习专栏》


• 《生活感想专栏》

身体健康方面，后面我还是要减减肥、增强免疫力，让身体保持健康的状态。

祝福大家

写到这里就没啥写的了，祝福大家身体健康万事如意，以身入局胜天半子。

两年前的这个时候，突然觉得说话特别费劲，舌头不太听使唤，左手突然不听话，就像李雪健老师表演那个帕金森老头喝酒一样。

我心里一慌，请假去了医院，验血，CT，超声。然后医生给我列了长长一篇诊断书：高血脂，高血压，糖尿病，冠心病，还有最可怕的脑出血，还好只是渗血，虽然并不是很严重，但是位置不太好，影响了身体感官和左手。

平时身体非常好，也经常运动，为什么会突然得这么多病呢。毫无征兆的左手就不听使唤了。而且听力在这一段时间也非常差。通过大夫诊断，一部分是遗传因素，另一个是和我常年酗酒，熬夜有关，每天几乎只睡3-4小时。

是的，，，，，，我喜欢在家喝着啤酒写代码，甚至有时候在单位加班的时候也是喝啤酒写代码。和别人不太一样，别人喝酒爱睡觉，我喝啤酒失眠。因为接了很多项目，上班之余都是晚上和周末熬夜写代码做自己的项目。

其实听到这个消息我很失望，失望的并不是因为身体垮了，钱还没赚够，而是我还没有完成我的目标就是打造一个自己主导的产品。

那天从医院回家，我并没有去坐地铁，而是从中日友好医院徒步走回天通苑的出租屋。在路上，我反复的想，今后的路该如何走。

继续在互联网行业工作肯定是不行的，病情会进一步加重，到时候就真的成一个废人了，反而会拖累整个家庭。如果不继续“卷”那我也就无法实现自己来北京的目标了。不过好在经过这么多年的积累，已经存够足够养老的资本，并不需要为妻儿老小的生存发愁，但是也没有到财富自由的程度。

躺平，躺到儿子回老家上学就回老家退休。这是一个并不那么困难的决定。但是却是一个非常无奈的决定，躺平就意味着自己来北京定下的目标没有完成，意味着北漂失败。

做好这个决定以后，我就开始彻底躺平，把手里的几个项目草草收尾，赔了大几十万。等于这一年白忙活。好在还有一份工作收入。同时也拒掉了2个新的Offer。在疫情最困难的时候，还能拿到两个涨薪offer。我还是蛮佩服我自己的。但是为了不影响我的额外收入，加上现在工作不是很喜欢，也就一直犹豫不决。但是这次生病彻底让我下定了决定 ---- 算了。

其实，经历这么多年，什么都看的很清楚，但是我的性格并不适合这个行业，我这个人最大的特点就是腰杆子硬，不喜欢向上管理，经常有人说我那么圆滑，肯定是老油条，而实际上，我整整18年的工作经历，只对领导说过一次违心的话，变相的夸了老板定制的开发模式，老板看着我笑了笑，也不知道他是不是听出来我这话是讽刺还是撒谎。

而其余都是和老板对着干，只有2任老板是我比较钦佩的，也是配合最舒服的。而且共同特点都是百度出身，我特别喜欢百度系的老板。特别务实，认认真真做业务。不搞虚头巴脑的事情，更不在工作中弄虚作假。一个是滴滴的梁老板，另一个就是在途家时候的黄老板。

当然，在我整个职业生涯有很多厉害的老板，有的在人脉厉害，有的人个人管理能力，有的在技术。但是由于我性格原因，我就是跟他们合不来，所以要么你把我开了，要么等我找好下家主动离开。

所以我的职业生涯很不稳定，就比如我见过的一个我认为在技术能力上最厉害的老板，也是我唯一在技术上佩服的人，就是在36kr期间认识的海波老师，听他讲的系统架构分享和一些技术方案，真的是豁然开朗，在Saas和Paas的方方面面，架构演化，架构升级所可能遇到的各种问题及面对产品高速迭代所需要解决的问题及方案都门清，而且他本身也是自己带头写代码，实际编码能力也是非常的牛，并不是那种“口嗨”型领导。但就是我跟他的性格合不来，最后我把他那套架构方案摸透了以后就跑路了，而从他那里学的那套技术方案，在我日后在lowcode和Paas以及活动运营平台的技术方案设计上帮助颇多。而他不久之后也离开了。据说去了字节。

混迹于形形色色的老板手底下，遇到过的事情非常多，也让我认清了一点，那就是，牛人是需要平台去成就的，平台提供了锻炼你的机会和让你成长的机会。所以你学到了，你就成了牛人。而不是你自己手头那点沾沾自喜的觉得别人没你了解的深入的技术点。所以平台非常重要，绝大多数情况下都是如此。

所以我这种人就不适合，因为我不喜欢违心。我顶多就是不说出来，不参与，不直接反对就已经是对老板最大的尊重了。所以我能看透很多事情，但是也知道我不讨老板喜欢，而我的性格也不可能为了让老板喜欢而卑躬屈膝，所以，我早早就提前做好准备，就是拉项目，注意这不是做私活。拉项目就是承包项目，然后找几个做私活的人给他们开发。这项收入有时候甚至一年下来比我的工资还要高。风险也是有的，那就是可能赔钱，十几万十几万的赔。所以也是一个风险与收益共存的事情。做项目的好处是，你可以不断的接触新的甲方，扩张自己的人脉，也就不断的有项目。

但是由于这次生病，我手头的3个项目都没有做好，都被清场了。所以为了弥补朋友的损失，我一个人扛下了所有。也同时意味着后面也就没项目可接了。身体不允许了。

躺平以后，为了等孩子回老家上学，本职工作上，也开始混，我最后一年多的时间里，写代码，都不运行直接就提测。是的。没错。。。。。。就是这样。但是功能是都好用的，基本的职业操守是要有的。虽然也会有更多的bug。但是一周我只干半天就可以完成一周的工作。这可能就是经验和业务理解的重要性。所以，我一直不太理解很多互联网企业精简人员的时候为什么精简的是一线开发人员，而留下的是那些只会指挥的小组长。这也是为什么各大互联网企业都在去肥增瘦，结果肥的一点也没减下去。

不是有那么一句话，P8找P7分一个需求，然后P7找P6喊来P5开发。互联网就是这样子，一群不了解实际业务和实际代码的人，在那里高谈阔论，聊方案，聊架构，聊产品，聊业务，聊客户，聊趋势，然后让那些一脸“懵逼”的人去开发。最后的结果可想而知，最后很多需求都是一地鸡毛，但是责任却都要一线执行去承担，而为了证明需求的正向收益，那就在指标口径上“合理”的动动手脚，所以我在我整个职业生涯说出了那么一次，也是唯一一次违心的恭维话。

所以我特别佩服一个网红叫“大圣老师”，是一个卖课的，虽然我看不上他做的割韭菜的事情，但是我很佩服他这个人，他也是很刚的人，就是看不惯老板pua和无意义的加班，人家就是不干了。成功开辟了第二职业曲线，而且也很不错。

另一个网红就是“神光”，虽然我也看不上他，但是我很佩服他，佩服他追求自我的勇气。

而反观那些在职场唯唯诺诺卑躬屈膝的人，现在过的如何呢？人啊。还是要有点个性。没个性的人下场都挺惨的。

峰回路转，人那，这一辈子就是命，有时候把，真的是你也不知道结果会是什么样，23年在我百无聊赖，闲的五脊六兽的时候，一周的工作基本上半天就干完了，所以一个机缘巧合，遇见了一群有意思的人。当时大模型正在风口浪尖。好多人都在大模型里面摸金，而有这么一群人，一群大学生，在海外对我们进行大模型技术封锁的时候，为了自己的初衷，建立了在问这个网站。

而作为起步比别人要晚，产品做的还很粗糙如何跟市场上的竞品竞争呢？而且不收费，更不打广告，完全靠赞助存活。但是这一切都是为了在国外封锁我国大模型技术背景下的那句话“让知识无界,智能触手可及”。站长原文

所以在同类起步更早，产品做的更精细的很多产品逐渐倒下去以后，zaiwen还活着。所以我觉得特别有意思，这种产品活下来的概率是非常低的，除非整个团队都是为爱发电，于是我也加入到这个团队。

事实上也确实这样，整个团队是有极少部分社会工作者和大部分在校大学生组成，而大家聚一起做这件事的初衷就是为了让知识无国界，让国内用户可以更方便的体验最先进的海外大模型技术。而目标用户，也都是学生，老师和科研工作者。

就这样在这里，我重新找回了自己的目标，虽然，由于资金问题，资源问题，以及我个人身体限制能做的事情很少，但是却发现，大家都做的非常有动力，产品也在不断的迭代不断的发展，并且还活的很好。团队的人在这里也干的很开心。

今天，正是两年前我诊断出脑出血的那天，心里没有低落，也没有失望，更没有懊悔，有的只是新的体验。人生啊，来这一世，就是来体验的，别难为自己。顺势而为，就像张朝阳说的那句话“年轻人挺不容易的，建议年轻人不要过度努力，太过拼搏的话（对身体）是有伤害的，年轻人得面对现实，这个世界是不公平的”

引言

2024 没啥成长的, 净剩下焦虑、内耗、失意了! 随便写写总结, 诸君随便看看吧...

一、落考(软考)

如题, 今年报考了软考(高项), 选择题和论文没过 😅😅😅 明年继续吧!!

去年在掘金读了好多篇年终总结, 偶然了解到了杭州 E 类人才, 杭州 E 类人才无疑对我这等普通人来说是可以触及到的, 而且优待 福利较高 的一类人才了。

而对于我等普通人来说, 通过 软考 + 专利/软件著作 是最便捷可行的一种。这其中唯一有难度的其实就是 软考了

软考是一种简称, 其全名是计算机技术与软件专业技术资格(水平)考试, 大家也称之为计算机软考、计算机软件资格考试等。软考又分为初级、中级、高级, 申请 E 类人才则需要高级资格证书, 这里直接报考高级就行(不需要从初级考起)。

如上图每个等级都有很多门专业, 今年我报考的是 信息系统项目管理师 简称 高项, 因为据说这门比较简单, 都是介绍项目管理上的一些知识, 背的比较多, 对专业要求没那么高。

当然如题, 今年没准备好, 有两门挂了 😭😭😭, 总共要考三门分别是选择题、案例分析、论文, 每门总分都是 75 分, 需要每门都考及格(45 分), 才算通过考试。

经验教训:

1. 一定要提前做好计划, 严格按照计划安排时间学习。 我自己就是中间有段时间公司活比较多、加上自己懈怠了, 后面就严重影响了进度


2. 一定要多刷题, 特别是选择题, 以刷题为主。我这次基本没刷选择题 🤦


3. 论文提前开始! 备好模版就开始写吧

二、车祸

是的, 不幸的是在 6 月底, 一天阴雨绵绵的傍晚, 在下班回家路上(家门口)骑着小毛驴的我和尊贵的宝马车主相撞了!!

被撞倒瞬间, 还是很刺激的! 整个大脑嗡嗡的, 思考 🤔 几秒, 原地蹦了起来!! 后面就是报警, 开具交通责任认定书(对方全责)。交警到场时看了下伤势, 说应该没事大事的。问我要不要去医院做个检查可以自己打车或者让司机送我去, 纠结了下还是打算去医院瞅瞅(后面回想起来也是后怕, 幸亏去了, 要不然可能半条命就没了...)!

到医院一通检查, 很不幸... 走不了了, 寰椎骨折得住院了 😱。医生看到片子后那一脸严肃的表情, 可把我吓坏了! 医生语气都变了, 让我赶紧坐下, 脖子不要乱动, 叫来了工作人员给我整了个颈托! 然后让我办理住院....

后面了解了下, 寰椎骨位于脑瓜子和脖子中间, 用于支持脖子的一个环形骨头, 骨头中间镂空的, 人的所有神经都是从这个环中间穿过到达身体各个地方, 所以这个位置骨折, 处理不好就可能会压迫到神经! 运气好的是我伤的位置比较好, 在脖子前侧, 如果是脖子后面可能就得开刀了!! 更庆幸的是, 来了医院做检查, 否则这条命可能就得交代了!!

后面住院 8 天, 过上了早 7 晚 10 的作息了, 每天就是看看电视、玩玩手机, 然后抽空就过道里溜达溜达, 提前过上了养老生活!!

出院后, 就开始居家办公咯! 中间还抽空搬了家, 然后还给自己整出了荨麻疹, 我也是醉了...

同时我的交通事故是发生在下班路上, 并且是对方全责, 所以还属于工伤! 故在受伤居家期间还申请了工伤。感慨下, 工伤流程也太麻烦了吧... 到目前为止还没整完 😤

最后友情提示, 出事不管怎样一定一定要报警(定责)、去医院做好检查...

三、祸不单行(失业)

9 月眼瞅着脖子马上要好了, 终于可以结束居家办公了! 接踵而来的是, 公司经营不善, 大规模裁员的消息!!! 所以自然的, 我又再次失业了!! 人生第二次失业了, 也没啥感觉, 该赔偿赔偿, 该滚蛋滚蛋!!

失业了, 三无人士, 一点也不带慌的, 该吃吃该喝喝! 这期间顺便处理了交通赔偿事宜, 虽然没多少! 伤好后, 去大西北溜达了一趟!

一下子没反应过来就到年底了... 只能怪今年太早过年了, 就这样办, 一切明年再议...

四、生活

今年重新找了住处, 顶楼, 再也不会被楼上邻居吵到了, 少了很多内耗, 就是夏天有点子热!! 同时房子也更大点了! 当然租金肯定也更贵了!

今年下厨的次数也明显多了起来, 出去吃大餐的次数少了挺多的! 上班也开始自己带饭咯, 当然省钱好像并没有省到, 自己煮饭量不好掌握, 一煮一大锅, 一吃一个不吱声! 同时大鱼大肉的, 一顿饭价格也不贵, 好在比外面吃健康点!

今年好像也没赞下什么大钱, 没有养成记账习惯, 所以一切靠感觉! 反正赞是攒了, 但是肯定没达到预期, 明年一定要养成记账的习惯

今年的韭菜长大了一点点, 感谢债基、感谢纳斯达克(明年能回本吗? 😵‍💫)

回顾下, 今年倒是去了不少地方, 一月迪士尼、三月苏州、六月昆明、十月武威张掖、十一月邯郸、十二月滑雪

家中新增一员, 名唤 二狗子! 刚入门就命运多舛, 感冒、流鼻涕、咳嗽不断.... 但也不影响她可可爱爱!

五、卷? 不卷?

今年的代码全部贡献给了 昆仑虚, 但实际上也没干啥, 就将 昆仑虚 迁移到 NextJS 并引入 TS, 代码量和去年比少得可伶!

内容创作这块也没啥成绩, 掘金输出 22 篇文章, 公众号「昆仑虚F2E」日常更新原创文章, 然鹅仅仅新增了 30 关注😓😓😓(这里求个关注)

内容创作收入: 掘金金石 +604、公众号收入 +13

卷吗? 今年一顿摆烂, 和去年给自己定的目标差太多咯.....

对了, 今年还读了 5+ 本书...

六、展望 2025

计划以及有了, 重点就三件事: 攒钱、卷、减肥。 更细节的就不列了, 直接看去年的吧, 基本差不多 !! 🤣🤣🤣🤣

一、前言

随着手机更新换代的加速，每个人都有一些功能正常，但是闲置的手机，其实现在的手机都是ARM架构的，大多数手机内存还不小，相对于现在各大厂商提供的云服务器来讲，配置已经很不错了，所以这么好的资源能利用起来还是非常不错的~

二、工具介绍

目前能用的工具有很多，比如BusyBox、Linux Deploy、juice ssh、termux，但是很多都是需要手机能够root的，但是root并不是所有手机都能够简单获取到的，所以我这里选取Termux进行操作。

三、什么是Termux

Termux 是一款运行于 Android 系统的开源终端模拟器。提供了 Linux 环境，即使设备不具备 root 权限也可使用。通过自带的包管理器（Pacman、 APT），Termux 可以安装许多现代化的开发和系统维护工具，例如 zsh、Python、Ruby、NodeJS、MySQL 等软件。

四、开始改造

4.1 Termux安装

Termux下载：github.com/termux/term…

安装完成后，可以执行以下命令更新一下各软件包：

pkg update && pkg upgrade

4.2 安装openSSH

成功安装Termux之后，虽然手机是可以像服务器一样执行一些操作，但是毕竟手机管理配置起来没有PC方便，所以可以安装SSH服务，方便PC来远程操作。

# 安装openssh

pkg install openssh



# 默认端口为8022，修改端口

sshd -p 8888



# 启动ssh服务

sshd