是时候在我这里聊一下人工智能了

疯狂的热度也该过了吧。

也是时候冷静的看待这个问题了。

这篇文章写得特别长。懒了，没有拆成多篇文章。

目录

• 一、个人初接触AI技术
  • 1. waifu2x
  • 2. style2paints
  • 3. rife
  • 4. 其他
• 二、爆火的 DeepSeek 把国际 AI 大厂的股票打废了
• 三、目前的 AI 到底能做些什么？
  • 1. 大型IT企业
  • 2. 中小型IT行业企业
  • 3. 非 IT 行业的企业
• 四、目前的 AI 在个人手中到底能做些什么？
  • 1. 作为问答式搜索引擎
  • 2. 写垃圾文案
  • 3. 编程
    • 项目
    • 功能片段
    • 繁琐复杂又没技术含量的代码
    • 复杂逻辑的编程
  • 4. 绘画
    • 尝试本地化
    • 放大图片工具
    • 去背景工具
    • 线上出图工具
    • 线上改图工具
• 五、目前我的态度
  • 1. 对个人
  • 2. 对各个企业
    • 国际
    • 国内
• 六、结论

一、个人初接触AI技术

1. waifu2x

我第一次开始接触并使用 AI 技术，应该是 waifu2x 这个图像缩放工具。

确切的说 waifu2x 并不是人工智能技术，只是使用了和目前人工智能技术相同的 「卷积神经网络」

这东西其实不用多介绍了。

这东西实用性能满足日常需求，而且本地部署也只需要不到50MB的空间，方便又整洁。

论清晰度其实 waifu2x 已经很不错了，尤其是平时出的原图的时候不符合各种破视频网站分辨率最低要求的时候，用 waifu2x 糊弄一个高分辨率图，然后再被这些破网站压缩成 320×180 的小图。

唯一想说的就是当时这个技术可是被小鬼滥用到极致，最火爆的期间各种互联网古董图片都被这些小鬼用waifu2x放大之后发到网上，然后大叫“我找到XXX的高清原图了！”。不明真相的人要是跟他讲这是“放大的”，他还会继续跟你解释“这是高清原图！”

你永远叫不醒一个装醒的人。

2. style2paints

接触到的第二个 AI 工具应该是 style2paints 。这是一个线稿上色工具。

最初接触这个软件的时候还是V3版本。

网上的AI线稿上色功能基本已经烂了，但是完成度也是稀烂，可以说根本没法用。

最早那一阵子还因为随便上色了一个线稿，画师直接就把我拉黑了。

style2paints 出 V4 的时候我写过这么一篇文章：https://blog.catscarlet.com/202002203604.html

后来 style2paints 出完 V4.5 之后，说要出 V5，而且放出了不少预览图，效果很棒，但是再也没有过下文。开发者在 GitHub 上还是活跃状态的，只不过全部都是私有提交了。

网上也再没出现过独立的开源上色工具。各个大厂虽然有各种所谓的线上AI图像处理工具，却基本上没有免费的线稿上色功能。收费的倒是一大堆，但是AI出图的效果本身就稀烂，谁知道输出一次期望中的结果之前得花多少冤枉钱。

3. rife

这算是第三个我使用的AI工具。功能是：补帧

最开始的时候这个项目还是叫做 arXiv2020-RIFE ，后来才改成 ECCV2022-RIFE 的。

但是实际上这玩意放在个人手里意义不是很大。最多就是把互联网早期的GIF表情包改得流畅一点，但是很多情况下 AI 对于补帧和人脑还是两回事。

bilibili：整了个支持Alpha图层GIF动画的放大加补帧转VP9的脚本

在有遮挡性的图像变动的时候，补帧出来的图像就会出错。4.22版本。

（我本地是有更新的模型版本的，但是执行的时候就会出现主机断电的状况。能确定不是电源供电不足，但具体是什么愿意无从得知）

现在这个技术也被滥用了。

• 网上有一堆原生30fps被补到60fps的动画资源，看着特别的果冻。也有电影，甚至 YouTuBe 上有 60fps 版本的 复仇者联盟1 看着就像游戏过场动画一样。
• 很多电视台的代理（IPTV）和电视盒上游，会把 30fps 的视频补到 60fps，看着十分的诡异。
• 最烂的当然还是显卡厂家，直接搞出 DLSS 这种帧生成的恶心玩意。

我自己看这种全局的恶意补帧视频时觉得就挺恶心的，头晕得很快。但是后来发现大多数人都是瞎子，别说补帧了，帧错误亮度错误对比度错误在他们眼珠子里都没有区别的，盯着一个坏掉的显示器看上几个小时愣没察觉到自己显示器是坏的旁边显示器是好的，瞎。

4. 其他

其他的基本上就没有接触过了。最多就是个 rembg 去背景工具，我也用不上。

再往前还有 AlphaGo，谷歌在打完围棋之后跑去打星际争霸，然后难产了好一阵子。最后不了了之，在网上搜谷歌AI打星际的视频，只能搜到一个播放列表，是 ArtosisTV 解说的 AlphaStar vs Serral，但是解说内容是基于非星际争霸玩家的，AI的每个行为以及星际争霸的每个兵种和技能都要解说一遍，中间夹杂着各种暂停和战术解释，节奏超级慢，12分钟的游戏解说了半个多小时，根本看不下去。这其间谷歌的AI就彻底凉了。

那几年 AI 爆火的时候 Python 从个只是底层干活的脚本语言一跃成为 不学 python 你就落伍了 这种骗术主流。我是懒得去学，这玩意个人学了也是屁用没有。AI 这种技术注定要被大厂捏得死死的。

二、爆火的 DeepSeek 把国际 AI 大厂的股票打废了

国产的 DeepSeek 把以 Nvidia 为首的国际AI大厂打废了，这是事实。但理由并不像国内鬣狗自媒体和阿Q人一样，因为鬣狗阿Q的思路就是成功啦崛起啦疯狂嗷嗷叫，谁叫得声音大谁有理。

Nvidia和其他大厂之所以市值蒸发，是因为他们一直声称的 需要更多硬件更多算力 是 扯蛋 。

确切的说， Nvidia 摆烂也不是有 AI 才开始的。先是在挖矿潮期间摆烂，后又开搞各种与游戏算力不相关的各种糊弄人的技术。其他各厂基本上也是一样，微软在那搞的 onnx 的也是稀烂（之前我参与修复的 rembg 不能正确使用硬件加速的 bug 就是 微软 onnxruntime 和 Nvidia-CUDA 联手造成的，可见其代码是有多烂）。

而一个名不见经传的 DeepSeek 却用了很普通的过时硬件做出来一个捅了行业技术天花板的产品，这直接戳破了 英伟、微软、英特尔 这么多年来一直给市值吹肥皂的核心理念。 算力不是最重要的 不需要什么大厂技术也能做 一直吹牛逼的玩意其实屁都不是 ，这乐子直接打得 Nvidia 的50系显卡一点都不香，微软的 Win12 不知道该怎么塞烂功能，英特尔的 Ultra 系列定位完全翻车。 活该！

至于 DeepSeek 究竟怎么样？看着那个推理过程好似挺有趣的，但其实推理流程过于营销号，复杂一点的问题就开始胡说，网上难搜到的东西就开始瞎编，就和其他 AI 一样。

（部分错误引用和内容均用红框标注）

这表现实在是太像一个初中没毕业结了婚有了娃，娃娃问你一些客观存在但你完全不知道的知识时，就在那瞎引用瞎推理瞎解释，着实一个爹味浓厚的鬣狗阿Q，着实让本来就生活在这种恶劣环境的人反胃。

三、目前的 AI 到底能做些什么？

首先这个得分场景考虑，也就是，AI 这项技术在谁的手里时才有什么用。

1. 大型IT企业

首先一个前提得讲清楚：

目前的 AI 技术就是 给一个算法喂数据养模型，当相应的数据是 由人类创作的 情况下就十分有争议，说难听点就是 抄袭 。编程AI抄代码，绘图AI抄绘画，医疗AI抄病例，这也是目前相当多一部分人反AI的核心理由。

我的个人观点是：

• 以一定的目的使用特定的数据训练AI并以此谋私利，那就是 抄袭 ！
• 将整个互联网数据全部用来训练AI，并公开数据模型，供所有人无偿使用，那不叫抄袭，那叫 人类的知识库 。

很可惜 人类的知识库 在目前的商业环境下实现不了。想使用 将整个互联网数据 的就只有大型IT企业，而目前的这些企业都是清一色的自私自利行业毒瘤，他们的存在多数都是对行业弊大于利，唯一的那点利也知识为了保住他们的自身地位罢了。（举例的话就是微软英特尔之流目前在开源界贡献的代码排在首位，但是他们贡献的全他妈的是他们自家用的驱动代码和调用代码，对整体行业有个屁用啊）

2. 中小型IT行业企业

首先中小型企业很少能有能力自己研究算法，在有限的资金和精力之下无法对行业技术作出突破性的贡献。你也不能怪罪他们，很多公司本身为了能正常运营就已经很努力了。

这才是行业真实现状。他们的产出才是老百姓真正能接触到和获益的。

目前据我能看到的，超市电子秤 可以说是一个不错的例子：传统的大型商超的果蔬摊位基本上都是要有个 负责称重的功能，有些是有专人上秤打标签，有些则是自主称重。现在很多超市都是AI电子秤，把果蔬放上去之后，能直接识别到品名（可能会识别到多种，再人工选择），这个工作量要比纯手选低多了（一个果蔬商超一般都有几十种甚至上百种标签）。当然，具体是如何实现的，我不知道，可能是电子秤公司自己训练模型，也可能傻屌公司每次都得调用一次大厂的云服务进行图像识别。

当然了！

也可能反过来，因为这些企业的领导人可能就不是IT行业出身的，很可能就是个投机人。

那么，答案只有一个了：《Employment for computer programmers in the U.S. has plummeted to its lowest level since 1980—years before the internet existed》

你甚至可以尝试阅读这篇文章的中文AI总结：《财富》：程序员就业降 – 豆包

事实上国内中小型IT行业企业的产品质量也已经进一步滑坡了，你可以看一下这个 用户端验证时间 的神奇逻辑：《海航888元的随心飞偷跑了！》，基本就是什么人要写个需要验证时间的代码结果直接丢给AI就复制粘贴了，人脑里连产品设计的逻辑基础都没有。

3. 非 IT 行业的企业

首先摆烂的一定不会是普通老百姓。

https://weibo.com/2645861077/Pi3jJBv1w

普通老百姓摆烂都抢不到热乎的。

更别说还有人人喊打的 AI 客服了。

四、目前的 AI 在个人手中到底能做些什么？

1. 作为问答式搜索引擎

因为目前的AI就是一个特速算法的搜索引擎，所以当搜索引擎用是最基本的功能。尤其是在如今搜索引擎（不论中外）的搜索结果质量都暴跌，很多人都期望能在AI上得到好一些的结果。

只不过AI也是从搜索引擎拿结果的……

啊不是，我要是自己愿意自己逐像素框选的话那我还问你干球？

这是怎么把一个街机游戏识别成 999 和 11eyes 的？还把俩游戏标题合并到一起了？

Jay Smith 的 Bad Romance 与 Lady Gaga 的 Bad Romance 是什么关系？你这 DeepSeek 这是要往哪里推啊？

我已经无语了。

不得不说很多问题有时候答案是烂得不行。

2. 写垃圾文案

简直是官僚主义形式主义的辉煌！废话文学的巅峰！狗屁不通高考满分作文上树！

当然我也找到了点正经有点用的功能，那就是语法检测。

这玩意对于非母语用户还行，就是也很喜欢在有得没得的地方反复胡扯。没有中文版是个遗憾。国内的产品会拿你的文档做训练，所以千万别用。

3. 编程

・项目

作为一个差不多快被社会淘汰的程序员，说实话，我到现在 IDE 还是在用 Pulsar （原 GitHub 被微软收购后被抛弃的 Atom 的社区派生版本）。什么AI插件我都没安装。

我对于 AI 编程不是很了解，我也不知道这玩意现在到底能干啥。反正大家都吹得天花乱坠的。于是找了某之名 AI 编程 IDE ，cursor，在本地试了一下。

我这手里有一些对我来说解决起来很麻烦的问题，就是不是我自己写的旧代码不兼容新环境的问题，工程量太大，业务逻辑完全不知道，我也不想去研究这些项目的具体实现。

我就想着，AI工具既然可以导入项目，那可不可以直接让AI把代码过一遍，然后针对新环境的版本把旧代码中不兼容的地方全找出来改掉。

想得美！现在的AI编程工具和搜索引擎一样，还是问答式的。

试着导入了一个项目，然后 cursor 一直不停的有得没得一直在废话一些毫不相关的东西，对于因新环境和新框架不兼容的问题一个都没发现。

不得不说，很多人活得非常的 人机 。

・功能片段

那既然，AI编程这玩意仍然是问答式的，那就干脆继续当搜索引擎用就罢了，根本不需要什么编程插件或IDE编辑器，更不需要什么按量付费编程接口。

事实上，AI在问答式编程输出的结果还挺不错，尤其是在很多 理论上可行且应该有人实现过，但周围所有认识的人都没接触过对应技术 的场景下极为有效，而作为一个腐朽的程序员，我没事就会遇到这种 技术上应该能实现但是我不知道对应技术的入口在哪，而身边完全更是没一个比我更了解响应技术领域的人 ，这时要是在像文中 《我是救兵请来的猴子》 提到过的环境下，至少身边人都会想办法帮你找对应的资源，但是事实上现在国内大部分公司，同事人人自危根本顾不上你，甚至有人巴不得你翻车然后下次被优化的就是你，领导更是觉得「员工遇上瓶颈」乃是天大的 职场PUA 机会，绝对不会放过。

比如 《从豆包下载无水印图片》 这个用户脚本的核心理念是 跨域下载并重命名图片 。本身下载并重命名图片是 HTML5 协议中<a>的的一部分，但是掺合上跨域后就报废了。理论上这是个安全无风险的功能，但是实际上就是做不到，封死了。绕路办法，如果在网上搜，大部分资源都是告诉你使用 <canvas> 对图片进行跨域下载，但实际上却有更好更干净的办法。这个的确在AI中可以搜到，而在传统搜索引擎搜索的时候，搜索结果却会被 <canvas> 的结果淹没。

・繁琐复杂又没技术含量的代码

在编程开发这一块中，有很大一块工作内容都是 繁琐复杂又没技术含量的代码，尤其是前端开发，经常要计算渲染后图像的位置，或者单个元素的样式。这一块基本没人愿意写，但是很多时候不写不行。

这种工作交给 AI 却是非常的巴适。

有些时候国内AI编程的确会给出点惊艳的地方，比如需要临时文件或文件夹的时候知道 mktemp 。微软这种背靠 GitHub 的 Copilot 甚至都只会原地拉屎。

但是却并不 100% 可靠。

・复杂逻辑的编程

上一点复杂逻辑，AI编程就很容易挖坑。

比如AI会犯最经典 初级程序员错误 ，第二次循环时忘记把标志位重置。

（原链接找不到了只剩下文件了）

以及基础命令经常想当然，上下文对应不上。

红框位置的 type -f 对应的是 文件 ，但是上下文里写得清清楚楚的是在处理 软链接，应该改使用的是 type -l 才对。

只要上一点逻辑，那出错的情况就特别多。而且由于这代码不是你亲自写的，所以你要重新读一遍所有代码才能理清其逻辑，之后才能找到 Bug 所在。

经典的 编程即是10%的时间写代码，90%的时间找bug，那 10% 才是编程的真正乐趣。而大范围引入AI进行编程后，编程是1%的时间写代码，99%的时间找bug。

把编程唯一的快乐送给AI，把屎留给自己吃。

4. 绘画

这一块既是最有争议的一块，亦是我用到的最多的一块。

说来也挺可乐的，程序员在AI领域用到最多的功能不是AI编程……但话又说回来，我自己会编程我为什么还要找一个不靠谱的AI给我添麻烦？没上过班没被同事坑过还是怎么回事？

其实2022年那阵我就接触过 dalle-mini ，然而当时AI绘图基本上只能到这个程度：

怎么说呢，有些输出的确是带着灵魂的，但是整体上一塌糊涂。你可以看到每个输出中都或多或少带着核心细节。

现在AI出图已经今非昔比了。

・尝试本地化

首先当然是尝试在本地部署这玩意。在网上搜了下，基本都在说 comfyui 。这玩意我看了一下，支持 Docker ，那就毫不犹豫部署了。

然而实际使用效果不太乐观。

comfyui 的默认模型出图基本是这样的：

离实际能使用差太多了。

而目前可以在线上无限次数使用的AI生成图像工具，我找到了两个：豆包和百度，他们的出图效果是这样的。

豆包：

百度：

百度英文解析：

（豆包不支持纯英文解析）

百度的出图效果要比豆包差一些，但是在关键字很少的情况下精度比豆包要高，但但是关键字超过一个限度之后百度的精度就急转直下彻底崩了。

我检查了一下，comfyui 应该是需要手动添加模型。但是我尝试了几个例子看起来很不错的模型，在执行到 VAE Decode 时，主机就会直接断电重启。

我个人认为应该不是电源供电不足的问题，因为在 KSampler 阶段，显卡就已经跑满 200w 了。同样的问题也在 rife 上出现过（前文也提到了），使用 4.22 模型就正常，使用 4.25 模型就会断电重启。虽然我也怀疑是显存不够的问题，但是 comfyui 比较小的模型只有 2G 多就会导致我断电重启，而 rife 4.25 模型与 4.22 模型都只有不足 20M ，这就不太像是显存不够的情况。而且我的显卡是 GTX1080 8G 版本的，实测最多也只用掉 6G 多一点。

只能怀疑是驱动问题了，毕竟 GTX1080 这个老显卡是诞生得比挖矿潮还早。但没有办法了，我之前把系统升级后（从 Linux Mint 20.3升级到 Linux Mint 22.1，基于Ubuntu20.04到Ubuntu24.04），驱动版本还是550，CUDA也只是从12.2升级到了12.4而已，而最新版本貌似是12.8。我也不清楚到底是 GTX1080 只能装这么高，还是有什么其他限制。Nvidia 官网倒是有一个 575版本，Linux Mint官方没说正式支持，我也不想试。毕竟即使跑 comfyui 的默认模型，显卡的噪音都超大，温度直达 70 度以上（风扇57%转速，再提高那噪音就真的难以忍受了），而仍然要等很久才能出一张图。

本地化部署这事只能暂时放弃，等有新电脑新显卡再说吧。

・放大图片工具

出图只能用线上工具，那顺带看看线上工具都有哪些功能，结果发现百度放大图片的功能效果竟比我本地的 waifu2x 要好。

（左图：百度放大。右图：本地 waifu2x 放大）

这我可接受不了。立刻把本地的图片放大工具换成 Real-ESRGAN ，测试一下。

把图片缩小，然后再用 Real-ESRGAN 放大，然后离谱的就来了。

（左图：Real-ESRGAN animevideov3 模型。右图：原图）

animevideov3 不知道为何图片变得有点鲜艳了？

（左图：Real-ESRGAN x4plus 模型。右图：原图）

x4plus 放大后竟然比原图还清晰！太离谱了。

这让我想起了网上传闻的「断崖上未融化的雪块被相机AI补全成坠崖的白色尸体」的乐子了。

・去背景工具

本地化了 rembg ，因为命令行真的太好用了，比起线上工具实在太方便。然而 rembg 的代码质量稀烂，依赖的环境（onnxruntime，cuda-cudnn）更是烂到彻底。为此做了不少工作。我根本就不是个写 Python 的。

反正最后调通了，而且把模型更新到了 birefnet ，效果比默认的 u2net 好非常多。

（左图：u2net 模型。右图：birefnet 模型）

（左图：u2net 模型。右图：birefnet 模型）

・线上出图工具

前文也讲了，我找到的可以在线上无限次数使用的AI生成图像工具有两个：豆包和百度。豆包出图效果比百度强一点。

只不过除了模型比较强大以外，豆包仍然有着所有AI图像生成工具都有的毛病：不听话

这完全不日系赛璐璐芳文社好吧，这都给干到韩国去了。

特别喜欢给妹子穿过膝袜。裤袜搞错就已经很烦了，裤子都给你忽略了。

我之前想搞一个倒霉OL妹子的插画想做个有连续剧情的系列，比如妹子加班后下班下大雨，顶着雨去地铁站，结果豆包不会画折叠雨伞，我总不能让妹子淋雨吧？这个就算是情节也实在太不礼貌了，结果发现豆包也不会画「湿衣服」，可乐。

百度却非常的会画「湿衣服」，不仅如此，貌似百度画出来的衣服全都是湿的。

发觉百度的输出都特别的色情……

然后是如果遇到AI完全不能理解的内容，出图就特别的诡异。

（开车很困难）

有时候干脆就是精神污染……

不仅如此，线上工具还有敏感词屏蔽词和谐词汇，而且理由也过于欧亨利了。

这是有多怕有人用AI生成「铁链女」的照片啊？

你就只能靠中国人的聪明才智绕过屏蔽词。

另一大问题就是让图像上拥有超过1个的关键性事物。

一个人拿着一个有特性的事物，或者两个人，就会出错。

貌似这个问题是AI的通病，AI不听话乃是日常，因为人类一句话能讲讲明白一件事情哪个关键词轻哪个关键词重是主观的，两个人能顺利交流那是电波对上了，不能顺利交流那至少一个人看另一个人是傻逼。AI 不一样，AI 没得交流，现在的 AI 只是「训练」出来的。

网上传闻 FLUX 就要靠谱很多，但是本地部署的要求则高得更加离谱。本来在研究这玩意期间发现需要研究的内容就不仅仅是 ComfyUI，还有 LoRA、ControlNet、IP-Adapter 这一堆看着就乱七八糟的玩意就烦了，我又不是专门画图的画师，专门画图的画师也不会用这种完全是另一个领域的工具坑自己。烦了烦了，不研究了。

・线上改图工具

这算是出图工具的子集。

百度的出图效果就巨烂，改图效果更是差劲。事实上百度的那个AI图像编辑废柴得不行。

而豆包则超可笑的只要看到特朗普就生成失败。

最后单独生成了个图片然后用 rembg 去掉背景后再用 GIMP P上去。

五、目前我的态度

1. 对个人

我目前个人认为，AI 在个人手里最多只是个大玩具。

讲了这么多工具类的产品，没有多少是能在生产生活中切实获益的。或许像抠背景这种工具在艺术照或者COS照方面能有点用途，或者黑白老照片上色（但是能本地化的上色工具我又没找到）。

可能做创作时可以用 AI 做一些单页插画。但是做漫画就很困难，因为内容的连续性基本无法维持，很容易崩坏。

编程方面，虽然有牛逼吹说有人完全靠AI开发了APP，我觉得那是真吹牛逼。仅是编程环境搭建这一块在任何人面前都是令人生畏的第一座大山，大部分人根本走不到 Hello World 这一步就早早崩溃了。

剩下的就只能用来做坏事了。

2. 对各个企业

・国际

英伟达微软英特尔，仨破玩意早崩早开心。就是不清楚先被 DeepSeek 揭开丑陋真面目后又被川普背后捅刀子的股票崩溃后，到底能对这仨死玩意有多大伤害。

其实我觉得 英伟达 内心是害怕的。当年挖矿潮，捅他刀子的并不是显卡商，而是 ASIC 。我觉得再过一段时间他就得挨真刀子，所以他得把 CUDA 这一块跟 微软 绑得死死的。

（至今我们仍然不知道 ASIC 将如何跨过 AI运行环境 这个门槛）

就是不知道其他大厂到底和英伟达是不是一条心。

而微软的 onnx 烂得曾让我想干脆把看到的 AI 小项目都改写成 腾讯 ncnn 的。这玩意如果要做对比的话：

• onnxruntime 和 cuda 组合起来的运行环境一般需要 2GB 到 几十GB 的硬盘空间（不包含模型文件），启动速度超级慢，安装各种依赖包很可能搞崩溃你的系统。跨平台安装有完全不同的安装依赖。在日常主机上安装高风险高困难，只有使用 Docker 这种容器才能安全的保证主机不被污染。
• 腾讯的 ncnn 则完全不需要用户安装任何依赖包，只要操作系统的驱动正确就可以了，整套环境是基于 Vulkan API 实现的，。整个运行环境大概在 几十MB 左右（不包含模型文件），非常的轻量。跨平台只要预编译对应的二进制文件即可。纯绿色。

然而一个巨大的门槛挡住了我，ncnn需要的编程语言基础是C系，对我来说完全是另一个领域，搞不定。

・国内

百度风投 和 DeepSeek 一栋楼。

腾讯有着最好的 ncnn 但是学习门槛略高，而且很明显国际老流氓们都提防着这个山寨王。

阿里？谁他妈的为了个问答系统还要专门安装一个浏览器，甚至产品主页都没适配PC端的桌面浏览器。烧钱疯狂投广告搞得各个平台都跟得了癣病似的。能滚多远滚多远。

国家超算互联网中心？我跟你讲要不是因为秋风于渭水写的这一篇DeepSeek R1 可免费/白嫖网页版一览，我都不知道这玩意存在。这玩意是来搞笑的吧，自己建了一个 DeepSeek 服务但是这鸡巴什么玩意？

互联网的里程碑在这破玩意嘴里被贬成了 在国际上的影响力相对较小

六、结论

个人观点，仅供参考。

这篇文章写到中途的时候发觉内容太多太长。想过从中间拆开，分成多篇文章发布，但想了半天，去他妈的。

尝试把 WordPress 从 5.2 版本 升级到 6.6 版本，把 PHP 从 7.4 版本升级到 8.3 版本。

任务艰巨得完成不了。

非常的崩溃。

前提

我现在的线上的博客，以及线下的开发环境，以及（如果还在不为我知的某个角落存在的话）商用用环境，都是 PHP 7.4 的。

最早些时候，应该算是2015年，正式入坑 PHP ，那时候基本是公司用啥，我用啥。PHP 5.2 5.4 5.6 都用过了，尤其是 5.2 大坑一大堆，摔过很多次。然后到 2016 年的时候终于用上了革新的版本 PHP 7.0。真爽。再后来开始自己独立开发环境，直接开了 DAMP 的坑，最初也是用的 7.0 版本，然后就很随意的升到 7.3 版本，主要是当时开发负担少。然后博客站也都升级到了 PHP 7.3。

再后来 2021 年接了一个外包项目。虽然当时 PHP 8.0 已经发布了，但是貌似周边支持都不怎么地。为了保证开发速度，直接用了 PHP 7.4 版本。当时还涉及到前端开发，Node环境也是大更新，很早之前一直用的各种热门前端库基本都死绝了。博客和本地开发环境也都升级到了 PHP 7.4，博客的 WordPress 程序倒是没变，还是 5.2 版本（这里埋了个大坑），只是偶尔会从官网下载代码包然后手动更新对应的文件，以修复些潜在的安全问题。

现在是2024年年末，就连PHP 8.0 都已经停止维护快满一年了，最新版本 PHP 8.3 也已经发布快满一年了。WordPress 都到了 6.6 版本了，一堆 WordPress 插件都已经停止 5.2 版本的支持了。

想趁着有时间有机会，把 PHP 和 WordPress 都升级了。

天真了。

第一天

首先是把线上的代码全备份一遍。这个毫无工作量，我之前写了个备份代码，直接就把自己的整站扒下来。然后把备份的站再部署到本地的开发环境上，再改几个数据库字段，就完事了。打开后台，先禁用所有插件，以便升级之需。

Apache2 和 MySQL 不用动，因为用的一直都是 Docker 的最新版本，这几年也没什么巨大的兼容性变化。

PHP 这块我不知道算不算麻烦。我把 PHP 从 7.4 到 8.3 的所有 不向后兼容变更 和 废弃功能 全都看了一遍。没多少，就几页，几分钟就看完了。个人感觉这么多变更，只有一条能实际影响到我日常开发工作，就是自 8.0 起不再支持 带有默认值的参数后面跟着一个必要的参数 。

其实个人工作中也很少这么用，因为易读性有点烂。论性能来讲的话这么写性能也很差，只不过以前工作过的公司里就有很多人这么写，主要是为了防止其他同事调用函数忘记传参（空参也是参）。

其余的改动基本影响不到我。我使用的基本都是 PHP 的官方建议用法，最多也就是会遇到某些外部库被遗弃然后有个平替的情况，比如数据库接口啥的，即使出错了立刻就能发现。

于是很自信的先把 PHP 环境升级到了 8.3 。因为是基于 Docker 的所以也完全不用担心环境污染的问题。

然后就崩了，WordPress 就打不开了。

这倒是意料之中，毕竟当年 WordPress 4.3 版本当年连 PHP 7.0 都不支持。我现在用的是 5.2 版本，最高能支持的 PHP 版本也才 7.3 ……

什么？7.3？但我已经用 PHP 7.4 跑了 WordPress 满 3 年了啊？？？

什么兼容性测试……

下载了个 wordpress-6.6.2 的包，按官方文档手动安装。 崩得一塌糊涂

全部删除了重新来，这回用官方的自动升级功能，直接从 5.2 升级 6.6。真神奇，WordPress 官网被墙了这么久了竟然能秒下 WordPress 的安装包，我也不知道他是走的什么渠道。PHP 就这点恶心，前台所有操作你都看不到任何细节，就像是在用 Windows 一样。

成功安装。然后 崩得一塌糊涂 。这回不仅崩得稀烂，而且由于没手工删除后台的旧文件，新旧文件混在一起，更是手足无措。

就这么搞了超过6个小时，一直干到后半夜三点多，搞不定。

放弃，睡觉。

然后严重失眠，抽搐。

第二天 白天

首先考虑下到底是 PHP 的问题还是 WordPress 的问题。

按理来讲我已经把 PHP 的升级文档都看完了，并没有什么会天塌一般的变更，但是 WordPress 这边的确天塌了。

先在 PHP 8.3 环境下运行一下我的其他项目看看，结果我的个人主页就崩了。

我用的是 2023 年 3.1.48 版本 的 Smarty，其基础版本是给 PHP 7.0 做的，可能旧了吧。

下载了最新版本的 smarty-5.4.1 ，然后

什么玩意？ implode is Deprecated ，我怎么不知道？

又去重新看了一遍 PHP.net 官网的 implode 文档和 PHP 升级文档。根本没有 Deprecated 。

然后在网上搜了一下，发现是 Smarty 的锅。而且 Smarty 还在 join 和 implode 之间反复横跳。更恶心的是，implode 和 join 在 PHP 7.4/8.0 中已经声明并废弃了 先数组后分隔符 的用法，但是在 Smarty 中却是强制要求 先数组后分隔符 ？甚至官方在 issue 里来来了句 Smarty is Smarty and PHP is PHP. 有病吧。而且你就算有病，你特么连个文档都没有，谁知道你有这种抽风的设计啊。

你要知道之所以我还用 Smarty 这种超级古董，就是因为这是一种 靠谱的、前后端分离、完全后端渲染、仅需要 HTTP 和 PHP 环境、不需要臃肿框架和特定语法，的网页渲染模式，是提供给搜索引擎最靠谱的传统模式。没有网页模板系统的话，想写这种纯后端渲染前端显示的页面，就只能 php 和 html 代码混写，非常的恶心。

现在 Smarty 抽风了，真就不知道以后还怎么不依赖框架写这种页面。我搜了下，Laravel 的 Blade ，和 Symfony 框架下的 Twig，貌似也可以独立使用，但是我对 Laravel 和 Symfony 基本一无所知，作为一个 PHP 开发者真是有点丢人。

话题扯远了，回到刚才。

我目前是不太想动我的个人主页的，这 WordPress 是大头，是主要内容。主页只是个入口。虽然主页改动起来并不困难，代码量少，Smarty 抽风的部分比较好找。但主页这一块我其实并不满意，主要是多语言这块用的传参而不是独立页面，很受搜索引擎嫌弃，基本上没收录，收录的也搜不到。但我的确没有精力和欲望去重做。

另一方面，WordPress这边，崩溃得最多的部分其实是插件。WordPress的代码质量本来就很堪忧了，第三方插件更是三脚猫，各种天花乱坠的不规范语法，可以说基本上都不能在 PHP 8.3 上运行。

另外我虽然看了 不向后兼容变更 和 废弃功能 ，但是 PHP 新版新增的语法糖也有点天花乱坠。我用的是最新版的 php-cs-fixer_v3.64.0 ，没配置好的话就会把那些插件的奇葩写法转写成 8.3 的语法糖，有时结果更是瞎眼，基本没有易读性。

综上考虑，先放弃 PHP 8.3 的升级。先把能通的条通。PHP 的升级难度应该不是最高的，但是底下这些撇不掉的小垃圾目前是必须要保且支持不到 PHP 8.3，没精力做修改。

放弃 PHP 8.3 继续用 PHP 7.4 。

第二天 晚上

看兼容性列表，WordPress 6.6 也是支持 PHP 7.4 的。

但是实际上 API 改动实在太大了，而 PHP 前端应用最恶心的一点，就是 出错了，不报错 。

即使开启了 define('WP_DEBUG', true); define( 'WP_DEBUG_LOG', true ); define( 'SAVEQUERIES', true ); ，也经常是

• 功能好像开了但是没开
• 功能好像崩了但是啥日志都没有
• 功能正常使用但是页面上打了一堆不知道哪里来的错误日志

面对如此大的一个工程而大部分代码逻辑都是不可靠的。升级到 6.6 实在是消受不起。

放弃 WordPress 6.6 ，只升级到比较近的版本。

要不然试试 5.5 吧，毕竟我在用的一款插件，作者自评最高支持到 5.5。

下了个 WordPress 5.5 的安装包，装完了。崩，但是崩得没有 6.6 多。

主题 graphene

不开插件，只看主题，首先就是文章的评论显示不出来。检查后发现是评论的API变了，而我的主题 graphene 是 1.9.4.3 版本的，不支持 5.5 。

有时候看其他人的代码就是折磨，代码里写法五花八门，空格TAB混着，一会拼接字符串，一会替换字符串。单引号双引号混着用，左边括号有空格，右边括号换行了。

说实话我都不知道这算不算改好了，反正现在是能显示出来。我更担心的是其实还有哪个不知道的角落还有错，但是看不到，毕竟 PHP 前端 出错了 不报错 。

官方倒是有个新版的 graphene，但是我现在用的这个主题就是我大量改动过的，因为 graphene 原版的代码实在是， 太错了 。好多代码完全不符合前端的理念。然后是颜色和界面也是要一点一点从设置里调，那复杂和麻烦程度，说真的我更乐意重写 HTML 和 CSS 。

我真的想过很多次自己做一个 WordPress 主题，这个想法可是足够老了。但是当时 WordPress 3 版本的主题文档就恶心到我了，真的超级麻烦。而到如今就 WordPress 现在的代码质量，我估计开发主题会更困难更恶心。

也是怪不得其他更轻量的博客程序能后追直上。

插件 Disable WordPress Core Updates

接下来是 Disable WordPress Core Updates 这个插件。

这个插件是为了禁用 WordPress 的界面更新的。但是其实只有一行有意义的代码：

add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );

首先 create_function 这个函数在 PHP 7.2 废弃，在 8.0 中删除，所以我改写成了。

add_filter('pre_site_transient_update_core', function ($a) { return null; });

然后就见证奇迹了。能用是能用，但是 pre_site_transient_update_core 这个字段我在整个 WordPress 代码中都没找到。为什么做一个 pre_site_transient_update_core add_filter 就能抑制 WordPress 界面提示升级？ 魔法啊？

然后开启这个插件的时候，更新页面是崩的。

魔法。

插件 NIX Gravatar Cache

接下来是 NIX Gravatar Cache 插件。

这是个把 Gravatar 头像缓存到本地服务器的插件，只不过早就死透了。我当时随便改了点代码对付着用，大部分时间没出错也就那样了。

首先是这段代码。（红色部分是我添加的改动）

不能直接执行 wp_enqueue_script 和 wp_enqueue_style ，要先执行个 add_action('wp_enqueue_scripts', 引用能调用那俩玩意的函数); 。外国人看这种超长的单词时不会眼花吗？

然后是这么一段代码。

WordPress 的 register_啥啥啥_hook(__FILE__, array($this, '函数名')); 写法全都作废了，要改成 register_啥啥啥_hook(__FILE__, array($this, '函数名'));

接下来底下那一节：

• 假如 路径不可写 且 路径为目录，报错

否则

• 假如 创建目录（权限777）失败 且 路径不为目录，报错

就这烂判断条件看得我脑子都快炸了也没弄明白为什么这破玩意能在我线上服务器上跑几年没报错，而我本地开发环境却根本跑不通。

而且这玩意讨厌就讨厌在于，确在我的测试环境下报错了，但是 WordPress 只是多了个 .php-error 的样式并且高出来 2em 的一节，但是一点错误日志都没有！！！ 出错了 不报错 。

最后还是靠自己写 debug 代码定位的问题。

这 TM 都是些不该是问题的问题，竟然多得到处都是。

2天，一点有效进展都没有。唯一有效收获就是这些屎山不碰就没事，一碰能崩得全身是屎。

反而自己写的没有引用那些垃圾玩意的插件和程序，没发现啥大毛病。

第三天

2天没啥进展，给我干懵了。

俗话说没事别升级，升级必出事。

原本的想法是先试着升级，如果不能平滑升级的话，大不了全摧毁了，然后把整个博客文章用导入的方法塞回去重建。如果插件出问题了，大不了找找看是否有新的替代品。结果搜了一下，靠谱的插件基本没有，一大堆商业推广的插件，和一大堆复合性插件，而且这些插件无论对 5.x 版本 还是 6.x 版本的兼容性都乱七八糟，问题解决不了，还有可能引入更多的问题。主题这边则是更不想换，一方面本身现在用的主题就是我大量修改过的，因为网上的各种主题，仅安全性就一塌糊涂，更别说 HTML 标准了。我这主题还是专门针对 1366×768 分辨率优化过的，能在 小屏幕 150% 比例正常显示。让我再去改个新的，工作量也是太大。

现在基本上没辙了。

PHP 这边其实还行，而且版本活跃度比较稳定。

在 https://packagist.org/php-statistics 能看出各版本使用占比都跟维护相关。但 7.4 版本 比 8.0 版本还受欢迎 属实乐了。

但是周边应用真的是质量山体滑坡。WordPress自 3.0 版本就开始崩，后面很多发展都很魔幻，就连编辑器都是靠社区兜底，到现在已经想不清楚这玩意的产品路线是啥了。

其他生态我也不清楚，毕竟作为一个 PHP 开发，我连 Laravel 和 Symfony 都没用过，商用产品都是用 ThinkPHP 应付的，当然最爽不过不依赖框架没有条条框框自己从头写。

但是像 Smarty 这种原行业标志都走奇葩路线了。可以说整个IT行业，基本上，正常的元老人物都退出舞台了，剩下的这些，刨去臭鱼烂虾，就只有偏执而扭曲了，假若走向歪路，那就没得旧，而这一点在开源社区上也极为明显（因为闭源商业的死不死没人关心），Godot 基金会开搞政治正确炮轰特朗普和动画头像用户，Linux 基金会直接开踢俄罗斯的代码贡献者。IT 行业现在就像是一个患了早期癌症的癌细胞轻微扩散病人，看似有救但却是谁都不想救。

结论

给我干哑火了，懵逼了，现在不知道咋整了。

「部分噩梦是因为本人在现实中遭受精神上的打击，使得心情低落，导致创伤后心理压力紧张综合征后，会在梦中体现。这种噩梦可能会引发一些疾病。」

——摘自维基百科「恶梦」词条。

声明：「本故事是做梦梦到的，如有雷同那你精神有问题」

章节一

找工作，出门去面试。

大下午，刚下完大暴雨，北京天黑得跟深夜一样。积水没过鞋。

面试地点在一个小区的四层小楼里。

天黑，小区里一个路人也没有。

到了楼下，从一个入口找到了一个特巨大的电梯，看着像货运电梯，但是保养得特干净，应该是被载人载货混用了。

电梯外边墙上一个大彩色海报，上面写着各楼层的用途：

• 1楼，美食城（请从正门进入）
• 2楼，酒吧（此电梯不到2楼）
• 3楼，用棕色的胶带贴住了
• 4楼，XXX幼儿园

我要去的是4楼，应该是个IT行业的公司，怎么是幼儿园？

我看看手机，离约定的面试时间还有一个多小时。不如直接上去看看是不是走错地方了。

坐电梯上到4楼，出电梯一看，楼层空无一人，有几个房间亮着灯，往里面看，装修的确像是个幼儿园，只不过里面都是空的。地上有些幼儿园家具和玩具，看起来以前是个幼儿园，只不过没在运营。

我继续往里走，看看能不能遇到个人，问问是什么情况，这是我等会要面试的地点吗？

章节二

突然从走廊对面呼啦啦上来好多人，挨个进房间开灯，好像在规划什么似的。我走进一看，领头的那个不是我以前的前同事W（代名）嘛！W也看到我了，赶紧互相打招呼。

W后面跟过来的人，我一看，这不都是以前我在公司时比我先离职的老前同事嘛！

我问他们这是在干啥，W说，老公司打算用个新名字开个子公司，把这里三楼四楼都租下来当公司了，人都是以前的老人，直接在这简单收拾一下就要开干了，今天就是过来看看四楼怎么分配工位比较合适，大家都过来看看，看完了之后在这团建，玩一下午，然后楼下应该是个美食城，还有酒吧，晚饭也直接在这解决，反正公司报销。

W问我：咋这么巧你咋上这来了？

我：我是来面试的，说是在这四楼。

W：那要是知道是你那还面个啥啊，直接来就行了。等会别走啊团建玩游戏直接带你一个。

随便看了一下，都是以前的老同事，互相寒暄一下，发觉之前出国的几个前同事都没来，还是满遗憾的。

章节三

不大一会，前同事们把最大的那个房间收拾出来了。原本应该是幼儿园的给小孩玩耍的活动教室，现在一堆大人在地上坐了一圈有说有笑。

我进屋，有的前同事看到我，一愣，「哎呦，老猫（代名）咋也来了」，我说我本来是来面试的，「那还面试啥啊你想要啥岗位等完事了直接跟我们说就行了。等会做游戏你可得在我们这一组啊。」

W：「那可不行，我先遇上的老猫，他就得跟我们一组了」

另一个前同事：「唉W你不能这样，你看我们组人少，你得给我们匀几个」

W：「那我把最后进屋那几个人匀给你！」

得，我还是个抢手货。

前同事M（代名。M以前是W的项目组组长）进屋，看到我，「呦，老猫来啦，你分哪个组了？」

W：「分咱们组了。」

M：「你给他手环了吗？」

W：「还没有呢。」

说罢，W拿出来个浅绿色的手环，直接套我手腕上了。「这是咱们公司的手环，也是门禁卡，你进门的时候刷这个手环，门就开了。另外今天做游戏咱们一个组的，手环颜色是一样的，都是浅绿色的。」

我看了一下周围，所有人手上都带着个手环，颜色一共四种，看来今天做游戏是分四组。

章节四

开始团建，做游戏。

第一个游戏，一个前同事竟然捧出来一摞 3DS 出来，第一个游戏竟然是要在 3DS 的一个排队游戏里比赛的。

然后果然我们组首推我第一个参赛……果不其然就拿了第一。怪不得每个组都想争取我当组员。

自己玩了第一个游戏，然后又看着老同事们继续玩。

我突然一愣，想起以前大家还在老公司的时候，开会啊，团建做游戏啊，都是有零食有饮料的，怎么现在没有了？

W：「这附近貌似还真没看到有超市，没买着。」

我：「我下楼去一楼那个美食城看看有没有吧。」

W：「你手环拿着呢吗？等会从3楼进来直接刷手环就能开门。」

章节五

我从货运电梯下楼，直接到了楼外，绕着整栋楼走了半圈，才看到整栋楼的正门。

天仍旧很黑，像深夜一般。

从正门进入，映入眼帘的，是一排排餐饮用的桌子，而大部分椅子则倒扣在桌子上，看起来像是很久没有用过一样。

继续往里走，看到有亮灯的柜台，有个人弯着摇拿着拖把在柜台后面拖地，也不像是在营业的样子。听到我的脚步后也没有站起来看我一眼的意思，弯着腰就回应了一句「还没到营业时间呢」，说罢就进里面的屋子了。

我四处看了一下。基本所有柜台都没有亮灯或者营业，都没有人在。

有个通向二楼的楼梯，但是整个楼梯都被椅子堆死了，根本不可能从那里上到二楼。

最里面有个柜台则是有个人坐在那玩手机，不过那个柜台连牌子也没有，看起来更像是值班的保安。

我过去问保安哪里能买东西，保安：「不营业。」

我又问从哪里能上楼，保安：「都说了不营业。」

我示意我其实是要去3楼4楼，保安竟然用嫌弃的眼光瞟了我一眼：「3楼4楼早就黄了好久了根本没东西，你上去干啥！」

章节六

没办法只能出大楼，然后走到大楼后门坐电梯再上去。

到了4楼，电梯打开，却发现整个楼层一丝光亮都没有。没有房间开灯，也没有人。我往里面走了一点，整个楼层除了我脚步声的回音之外，什么都没有。没开灯，房间里有什么也看不到。

很伤心的从电梯下楼，到楼下，外边又下起来大暴雨了。

门前积水很快就涨了上来，水深得能划船。

章节 Nostalgic PTSD

想拿手机看看几点了，却发现自己手腕上还套着手环，只不过在这乌七八黑的大黑天里，手环不是浅绿色的，是橙棕色的。

醒了。

快速开始

在使用 VSCode 的过程中，你可以通过使用 Remote-SSH 插件来连接到远程服务器，然后使用 Monitor Pro 插件对远程服务器的资源进行监控。

1. 安装和配置 Remote-SSH 插件：

   • 打开 VSCode，点击左侧栏的扩展按钮。
   • 在扩展商店搜索并安装“Remote-SSH”插件。

2. 连接到远程服务器：

   • 安装完成后，在 VSCode 的终端中输入相关命令来连接到远程服务器。例如，可以使用ssh 用户名@远程服务器地址命令进行连接。

3. 使用 Monitor Pro 插件进行资源监控：

   • 安装 Monitor Pro 插件。这个插件可以帮助你实时跟踪重要的系统指标，并提供直观的展现方式。
   • 安装后，该插件会自动启用，并且你可以通过 VSCode 的状态栏查看当前的资源使用情况，如 CPU、内存、磁盘等。

4. 刷新设置：

   • Monitor Pro 插件允许你设置更新资源指标的刷新间隔，确保能够及时获取最新的资源使用数据。

如何安装和配置 Monitor Pro 插件？

安装 Monitor Pro 插件

在 VSCode 界面的左上角，点击“扩展”（或按 Ctrl + Shift + X），然后在搜索框中输入“Monitor Pro”。

找到“Monitor Pro”插件后，点击“安装”按钮即可完成安装。

配置 Monitor Pro 插件

安装完成后，会在 VSCode 的活动栏中看到一个新图标，点击它以启动 Monitor Pro 插件。

根据具体需求，可以在 Monitor Pro 的设置页面中进行相应的配置，比如调整监控项等。

部分支持的远程资源监控指标

1. CPU 使用率：监控 CPU 的利用百分比。
2. 内存使用率：监测系统的内存使用情况。
3. 网络使用率：跟踪网络的使用情况。
4. 文件系统使用率：监控文件系统的使用情况。
5. 电池百分比和充电状态：监测设备的电池百分比和充电状态。

最佳实践

1. 实时跟踪关键指标：Monitor Pro 是一个全面的资源监控工具，可以帮助你实时跟踪重要的系统指标。因此，建议定期检查这些指标以确保系统的稳定性和性能。

2. 直观展现方式：Monitor Pro 提供直观的展现方式，这有助于快速识别问题所在。利用这一点，可以及时发现并解决潜在的性能瓶颈。

3. 内存优化：虽然 Monitor Pro 主要关注的是资源监控，但结合其他工具如 Memory Monitor 和 Allocation Tracker，可以进一步优化内存使用。例如，通过 Memory Monitor 查看整个应用所占用的内存，并注意 GC（垃圾回收）操作的频率和时机，以避免内存抖动等危险信号。

4. 定制化配置：根据你的具体需求，对 Monitor Pro 进行定制化配置。例如，可以选择监控特定的资源，从而更有效地管理和优化资源使用。

This message is used to verify that this feed (feedId:42331815237783574) belongs to me (userId:55156152962822144). Join me in enjoying the next generation information browser https://follow.is.

本文将指导你如何为一个结合了 Prisma 和 Nuxt.js 的全栈项目创建优化后的 Docker 镜像，并使用 pnpm 作为包管理器。

我的项目最终镜像大小从 1.12GB 缩减到了 160.21MB。

我的项目构成

Nuxt.js 是一个基于 Vue.js 的服务器端渲染应用框架，非常适合于构建现代化的 Web 应用。

我的项目直接采用 Nuxt 构建全栈项目。

• Nuxt3
• Prisma
• PNPM

开始构建

首先，我们将使用 node:20-alpine 这个更轻量级的基础镜像来减小最终镜像的大小。Alpine Linux 因其安全、简单且体积小而广受欢迎。

多阶段构建是减少 Docker 镜像大小的有效策略之一。我们将使用三个阶段来构建我们的镜像。

第一阶段：构建依赖项

1
2
3
4
5
6
7
8
9
10
11

ARG NODE_VERSION=node:20-alpineFROM $NODE_VERSION AS dependency-baseWORKDIR /appRUN npm install -g pnpmCOPY package.json pnpm-lock.yaml ./RUN pnpm install --frozen-lockfile`

这一阶段负责安装我们项目的依赖项。我们使用了 pnpm 来代替 npm，pnpm 在缓存和磁盘使用上更为高效。

大部分项目也用 pnpm 而不是 npm 作为包管理工具了。

第二阶段：构建应用程序

1
2
3
4
5

FROM dependency-base AS production-baseCOPY . .RUN pnpm run build

在这一阶段，我们复制了项目代码并执行构建命令。这里的构建指的是 Nuxt.js 的构建过程，它会生成静态文件和服务器端渲染所需的资源。

第三阶段：生成生产镜像

1
2
3
4
5
6
7
8
9
10
11
12
13
14

FROM $NODE_VERSION AS productionCOPY --from=production-base /app/.output /app/.outputENV NUXT_HOST=0.0.0.0 \    NUXT_APP_VERSION=latest \    DATABASE_URL=file:./db.sqlite \    NODE_ENV=productionWORKDIR /appEXPOSE 3000CMD ["node", "/app/.output/server/index.mjs"]

最后，我们创建了适用于生产环境的镜像。这个镜像仅包含用于运行应用程序的必要文件，减少了不必要的层，使得镜像尽可能地保持精简。

我们还定义了一些环境变量，比如 NUXT_HOST 和 DATABASE_URL，这些是 Nuxt.js 应用和 Prisma 所需要的。其中，DATABASE_URL 被设置为使用项目根目录下的 SQLite 文件作为数据库。

最终通过暴露端口 3000 并指定启动命令来运行 Nuxt.js 应用程序。

不同构建方式的镜像大小比较

分别为：

• 3 步构建
• 2 步构建
• 直接构建

Dockerfile 总览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

# Use a smaller base imageARG NODE_VERSION=node:20-alpine# Stage 1: Build dependenciesFROM $NODE_VERSION AS dependency-base# Create app directoryWORKDIR /app# Install pnpmRUN npm install -g pnpm# Copy the package filesCOPY package.json pnpm-lock.yaml ./# Install dependencies using pnpmRUN pnpm install --frozen-lockfile# Stage 2: Build the applicationFROM dependency-base AS production-base# Copy the source codeCOPY . .# Build the applicationRUN pnpm run build# Stage 3: Production imageFROM $NODE_VERSION AS production# Copy built assets from previous stageCOPY --from=production-base /app/.output /app/.output# Define environment variablesENV NUXT_HOST=0.0.0.0 \    NUXT_APP_VERSION=latest \    DATABASE_URL=file:./db.sqlite \    NODE_ENV=production# Set the working directoryWORKDIR /appEXPOSE 3000# Start the appCMD ["node", "/app/.output/server/index.mjs"]

环境

• NX
• PNPM
• lodash-es
• Jest

从 karma 转移到 Jest 遇到了如下报错

主要原因是 “node_modules” 文件夹中 ESM（ECMAScript Modules） 库不被 Jest 支持。

鉴于 Jest ESM 支持还在几乎不可用的试验阶段，而目前我主要是在公司项目上迁移到 Jest。所以本文主要采用 transformIgnorePatterns 和 moduleNameMapper 两种配置来解决这个问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Test suite failed to runJest encountered an unexpected tokenJest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.Out of the box Jest supports Babel, which will be used to transform your files into valid JS based on your Babel configuration.By default "node_modules" folder is ignored by transformers.Here's what you can do:    • If you are trying to use ECMAScript Modules, see https://jestjs.io/docs/ecmascript-modules for how to enable it.    • If you are trying to use TypeScript, see https://jestjs.io/docs/getting-started#using-typescript    • To have some of your "node_modules" files transformed, you can specify a custom "transformIgnorePatterns" in your config.    • If you need a custom transformation specify a "transform" option in your config.    • If you simply want to mock your non-JS modules (e.g. binary assets) you can stub them out with the "moduleNameMapper" config option.You'll find more details and examples of these config options in the docs:https://jestjs.io/docs/configurationFor information about custom transformations, see:https://jestjs.io/docs/code-transformation

以下配置主要以 lodash-es 作为参考。

transformIgnorePatterns

官方文档的解释是：正则表达式模式字符串的数组，在转换之前与所有源文件路径匹配。如果文件路径与任何模式匹配，则不会对其进行转换。
即 transformIgnorePatterns 用于指定在进行代码转换时应该忽略的文件或文件夹。

而在 NX 默认的 Jest 配置中，配置为 node_modules/(?!.*\\.mjs$)。
这个正则表达式的含义是，匹配以 node_modules/ 开头的文件夹路径，但排除那些以 .mjs 为扩展名的文件夹路径。?! 是一个否定预查，表示不匹配这样的文件夹路径。

1

transformIgnorePatterns: ['node_modules/(?!.*\\.mjs$)'],

以上配置意思就是将会把以 .mjs 为扩展名的文件从 ESM 转换为 CommonJS，以支持 Jest。

添加转换 lodash-es

顺便支持一下 PNPM

1
2
3
4
5
6
7

const esModules = ['.*\\.mjs$', 'lodash-es'].join('|');export default {    ...    transformIgnorePatterns: [`node_modules/(?!.pnpm|${esModules})`],    ...}

转换后 failed 数量从 15 减少到 11，但是这么做会有一个转换的过程会有额外的支出，需要 51s。不过第一次转换完后貌似就会缓存然后就不用转换了。

支出更少的方法 moduleNameMapper

这种方法需要库本身有对应的 CommonJS，就不需要转换了。可以跑到 12s

1
2
3
4
5
6
7

export default {    ...    moduleNameMapper: {        '^lodash-es$': 'lodash',    },  ...}

最终配置参考如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/* eslint-disable */const esModules = ['.*\\.mjs$'].join('|');export default {  displayName: 'pc',  preset: '../../jest.preset.js',  setupFilesAfterEnv: ['<rootDir>/src/test-setup.ts'],  coverageDirectory: '../../coverage/apps/pc',  moduleNameMapper: {    '^lodash-es$': 'lodash',  },  transform: {    '^.+\\.(ts|mjs|js|html)$': [      'jest-preset-angular',      {        tsconfig: '<rootDir>/tsconfig.spec.json',        stringifyContentPathRegex: '\\.(html|svg)$',      },    ],  },  transformIgnorePatterns: [`node_modules/(?!.pnpm|${esModules})`],  snapshotSerializers: [    'jest-preset-angular/build/serializers/no-ng-attributes',    'jest-preset-angular/build/serializers/ng-snapshot',    'jest-preset-angular/build/serializers/html-comment',  ],};

参考

1. Jest setup "SyntaxError: Unexpected token export"
2. Configuring Jest · Jest
3. ECMAScript Modules · Jest
4. Configuring Jest · Jest

为什么用 Composition API

1. 使逻辑分离更容易：使用可组合函数可以将组件的逻辑分解为多个较小的部分，不再限制于 Options API 中组织代码，更容易重用有状态逻辑。
2. 灵活性和代码重用性：可以提取和重用共享逻辑，分离关注点，使代码更加模块化和易于维护。
3. 实现组件的复用和组合：将逻辑拆分为可重用的部分，使用可组合函数组合组件，避免重复编写代码，提高代码的重用性，减少重复和不一致性的风险。
4. 更好的可读性和可理解性：每个可组合函数封装了特定方面的行为、方便推理和测试、有助于团队合作，使代码结构化和有组织。
5. 更好的类型推断：使用变量和标准 JavaScript 函数处理组件逻辑。更容易在使用静态类型系统（如 TypeScript）构建大型 Vue 应用程序时进行类型推断

为什么解构 Proxy 会失去效应性

等待补坑

为什么 Vue 中解构 props 会失去响应性

在 Vue 3 中，当你解构 props 时，可能会丧失响应性。这意味着对 props 的更改不会触发组件的更新。

原因是 Vue 的响应性系统依赖 Proxy 来跟踪对象属性的更改。当组件接收到一个对象作为 props 时，Vue 会为该对象的每个属性设置响应性的 getter 和 setter。这使得 Vue 能够检测属性何时更改并相应地更新组件。

当你解构对象 props 时，实际上是创建了一个不再具有响应性的新对象。Vue 为原始对象创建的响应性 getter 和 setter 不会转移到新对象上。

参考

1. Vue3 如果解构 props 会失去起响应性导致 setup 里一堆 pros.xxx 怎么办？ - 这似谁的小鹿的回答 - 知乎
2. Vue Tip: Destructure Props in Composition API Without Losing …
3. How To Destructure Props In Vue 3 Without Losing Reactivity | by Nicky Christensen | Medium

为什么 Vue 项目很少用 RxJS

一句话解释

这是因为 Vue 希望成为一个轻量且灵活的框架，允许开发者选择他们喜欢的工具和库。虽然 RxJS 是一个强大的响应式编程库，但 Vue 采用了不同的方法，提供了自己的响应式系统。

详情点

• 设计理念不同：Vue 注重简单和直观，便于响应式编程；而 RxJS 功能更强、更复杂，适合异步和事件驱动编程。
• 库的大小与复杂性：RxJS 库大且学习曲线陡，若作为 Vue 的默认依赖，会增加框架大小和开发复杂性，与 Vue 的轻量和灵活理念不符。
• 灵活性：Vue 设计为灵活且适应不同的项目需求。不将自己绑定到特定的响应式库（如 RxJS），允许开发人员选择最适合他们需求的工具和库。这种灵活性使开发人员能够无缝地将 RxJS 或其他任何库集成到 Vue 项目中。
• 学习曲线：Vue 拥有平缓的学习曲线，特别是对于初级开发。通过提供自己的响应式系统，Vue 可以提供更简单、更渐进的学习体验。

参考

1. Introduction to VueJS and RxJS - This Dot Labs
2. Integrating RxJS with Vue.js | DigitalOcean
3. Reactive Programming: The Good and the Bad | goodguydaniel.com
4. A better practice to implement HTTP client in Vue with RxJS for enterprise Apps | by Pawel Woltschkow | Medium
5. You might not want Rxjs

Promise 与 RxJS Observables 的区别

Promise

• Promise 是 JavaScript 中内置的，不需要任何额外的库。
• Promise 表示可能现在或将来可用的单个值。
• Promise 是急切的，也就是说一旦 Promise 被解析，.then()回调会立即执行。
• Promise 只能发出单个值。
• Promise 非常适合处理产生单个结果的简单异步操作。

RxJS Observables

• Observables 是 RxJS 库的一部分，需要额外安装依赖。
• Observable 表示可以随时间发出的值流。
• Observable 是惰性的，也就是说在订阅之前不会执行任何操作。
• Observable 可以发出多个值，包括零个或多个值。
• 可以使用各种 RxJS 操作符对 Observable 进行转换和组合，以创建新的定制流。
• Observable 非常适合处理复杂的异步操作，例如实时数据流或事件驱动编程。

参考

1. JavaScript Theory: Promise vs Observable - Medium
2. angular - What is the difference between Promises and Observables? - Stack Overflow
3. JavaScript Promises vs. RxJS Observables

模版语法的简单实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const name = 'Nexmoe';const message = 'My name is {{name}} and I\'m {{getAge(20)}} years old.';function getAge(age) {  return age;}const replacedMessage = message.replace(/\{\{(.*?)\}\}/g, (match, variableOrFunction) => {  const trimmedValue = variableOrFunction.trim();  if (trimmedValue.includes('(')) {  // 如果占位符包含括号，则表示为带参数的函数替换    const [functionName, ...args] = trimmedValue.split(/\(|\)/).filter(Boolean);    const func = eval(functionName);    return func(...args);  } else {  // 否则为变量替换    return eval(trimmedValue);  }});onsole.log(replacedMessage);

先检查占位符中是否包含括号，如果包含括号，则表示是一个带参数的函数调用。使用split方法和正则表达式来解析函数名和参数，并将其存储在functionName和args变量中。然后，使用eval函数将函数名转换为实际的函数对象，并使用扩展运算符 (...) 将参数作为参数列表传递给函数。函数执行后，将返回值作为替换后的字符串返回。

如果占位符不包含括号，则表示是一个变量。直接使用eval函数将变量名转换为实际的变量值，并返回其值作为替换后的字符串。

⚠️ 注意：使用eval函数执行代码具有一定的安全风险，因为它可以执行任意的 JavaScript 代码。有相当多的建议建议不使用eval。准备过段时间研究研究不用eval的方法。

MVVM 是什么

MVVM 代表 Model-View-ViewModel，在 MVVM 中，Model 表示应用程序的数据和业务逻辑，View 表示用户界面，ViewModel 充当 Model 和 View 之间的中介。

模型（Model）

• 模型代表应用程序中的数据和业务逻辑。
• 它可以是从服务器获取的数据、本地存储的数据或通过其他方式获取的数据。
• 模型通常实现了一些方法来操作、存储和管理数据。
• 对应的是组件中的 data、props 属性。

视图（View）

• 视图是用户界面的可见部分。
• 它负责展示数据给用户，并接收用户的交互操作。
• 在 Vue.js 中，视图通常由 Vue 组件表示，可以包含 HTML 模板和样式。

视图模型（ViewModel）

• 视图模型是连接模型和视图的中间层。
• 视图模型通常包含了与视图相关的数据、计算属性和方法，以及与模型交互的逻辑。
• 通过双向绑定（data-binding）将视图和模型连接起来。当模型中的数据发生变化时，视图会自动更新。通过 DOM 事件监听，当用户在视图中输入数据或进行其他交互操作时，视图模型会自动更新模型中的数据。

优势

• 分离关注点：将数据逻辑与视图逻辑分离，使代码更易于维护和测试。
• 提高开发效率：通过双向数据绑定和声明式编程风格，减少了手动操作 DOM 的代码量。
• 可重用性：通过组件化的方式，视图和视图模型可以在不同的应用程序中进行复用。
• 响应式更新：当模型中的数据发生变化时，视图自动更新，提供了更好的用户体验。

参考

1. 为什么尤雨溪尤大说 VUE 没有完全遵循 MVVM？ - 知乎
2. Vue 的 MVVM 思想（包含三个常见面试题） - 掘金
3. MVC，MVP 和 MVVM 的图示 - 阮一峰的网络日志
4. Getting Started - vue.js
5. Comparing Vue.js to new JavaScript frameworks - LogRocket Blog

MVC 是什么

MVC 这个概念已经存在很久了，用了这么多年，今天了解一下概念做个总结。

MVC（Model-View-Controller）设计模式将应用程序中的对象分为三个角色：模型（Model）、视图（View）和控制器（Controller）。该模式不仅定义了对象在应用程序中的角色，还定义了对象之间的通信方式。每种类型的对象都通过抽象边界与其他类型的对象分离，并在这些边界上与其他类型的对象进行通信。应用程序中某种 MVC 类型的对象的集合有时被称为层，例如模型层。

模型（Model）

• 封装应用程序特定的数据，并定义操作和处理数据的逻辑。
• 可以表示应用程序中的实体，如游戏中的角色或地址簿中的联系人。
• 可以与其他模型对象建立关联，形成对象图。
• 应该存储应用程序的持久状态数据。
• 不应与呈现数据和用户界面相关的视图对象直接连接。

视图（View）

• 用户可见的对象，负责显示数据和响应用户操作。
• 知道如何绘制自身，并可以与用户进行交互。
• 通常通过控制器对象从模型对象中获取数据进行展示和编辑。
• 在 MVC 应用程序中与模型对象解耦，提供一致性和重用性。

控制器（Controller）

• 充当视图对象和模型对象之间的中介。
• 负责处理用户操作，并将其传递给模型层进行数据处理和更新。
• 可以执行应用程序的设置和协调任务，管理其他对象的生命周期。
• 在模型对象发生变化时，将新的模型数据传递给视图对象进行显示。

优势

• 提供良好的应用程序设计，使对象更具可重用性和接口定义明确性。
• 支持应用程序的可扩展性，易于添加新功能和模块。
• 分离关注点，使代码更易于维护和测试。
• 应用程序的模型层、视图层和控制层之间保持了清晰的分离，实现了代码的结构化和职责的明确划分，从而提高了应用程序的可维护性和可扩展性。

参考

1. https://developer.apple.com/library/archive/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html

为什么 Bun 这么快

JavaScriptCore 引擎

Bun 使用 JavaScriptCore 引擎，这是 Safari 浏览器使用的引擎，而不是基于 Chromium 的浏览器和 Node.js 使用的 V8 引擎。JavaScriptCore 引擎经过了针对更快启动时间的优化，这有助于 Bun 的速度。

性能分析和优化

大量的性能优化。Bun 的初衷就是要快。[2]。

Zig 语言

Bun 利用 Zig 语言进行低级内存控制和消除隐藏控制流。Zig 的设计原则注重性能，通过利用 Zig，Bun 可以实现更好的内存管理和控制，从而提高速度 [2]。

参考

1. Bun 1.0 | Bun Blog
2. A first look at Bun: is it really 3x faster than Node.js and Deno? - DEV Community

最近在服务器上面自建了 Sentry。

用 script 方法加入到网站后，始终没有效果，然后在控制台中发现了下面的报错。

The Sentry loader you are trying to use isn’t working anymore, check your configuration.

于是去 Github 上找了下，看着应该是国内网络的问题。

在 sentry/sentry.conf.py 内添加下面内容可以解决。

1

JS_SDK_LOADER_DEFAULT_SDK_URL = "https://browser.sentry-cdn.com/%s/bundle.tracing.replay.debug.min.js"

然后记得重启 Sentry 的 Docker 服务

1
2

sudo docker compose restartsudo docker compose up -d

• Sentry JS lazily-loadable loader doesn't work · Issue #22715 · getsentry/sentry

今天在网上找了些 PNG 格式的动态表情包我是不会告诉你是我是在 LINE 偷的表情包的，于是了解到是 APNG 这种格式。由于微信和 QQ 不支持 APNG，所以就把 APNG 转为 GIF 了，在使用 APNG 转换成 GIF 后，发现在微信上只能播放一次，就产生了如何批量修改 GIF 的循环次数的问题。

所以准备简单介绍一下 APNG。并提供了一个在线工具，可以将 APNG 批量转换为 GIF，但是该工具不能实现无限循环。所以分享了一个批量修改 GIF 循环次数的方法，使用了 Node.js 和批处理脚本两种不同的实现方式。方便 Node 开发者和使用 Windows 的普通用户直接批量处理。

APNG 是什么？

APNG（Animated Portable Network Graphics）是 PNG 的位图动画扩展，可以实现 PNG 格式的动态图片效果。APNG 相比于 GIF 在图片质量和细节表现方面更有优势，而且随着越来越多的浏览器对 APNG 的支持，它有望成为下一代动态图的标准之一。主要有以下区别：

1. 图片质量：GIF 最多支持 256 种颜色，并且不支持 Alpha 透明通道，这导致 GIF 在色彩丰富的图片和含有半透明效果的图片上质量较差。而 APNG 可以支持更高质量的图片，包括更多的颜色和 Alpha 透明通道，使得动画效果更加细腻。

2. 构成原理：APNG 和 GIF 都是由多帧构成的动画，但是 APNG 的构成原理允许超自然向下兼容。APNG 的第一帧是标准的 PNG 图片，即使浏览器不认识 APNG 后面的动画数据，也可以无障碍显示第一帧。而如果浏览器支持 APNG，就可以播放后面的帧，实现动画效果。

3. 浏览器支持：从 Chrome 59 开始，Chrome 浏览器开始支持 APNG，使得大部分浏览器都能显示 APNG 动画。唯独 IE 浏览器不支持 APNG。

更多内容请参考：https://xtaolink.cn/268.html

APNG 批量转 GIF

该工具可以批量将 APNG 转为 GIF，不过不能无限循环。

https://cdkm.com/cn/png-to-gif

批量修改 GIF 为无限循环

bat（普通用户请使用该方法）

下面是使用批处理脚本（.bat）来实现相同的功能：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@echo offsetlocal enabledelayedexpansionset "directoryPath=C:\path\to\directory"for /r "%directoryPath%" %%f in (*.gif) do (    echo Modifying %%~nxf    call :modifyGif "%%f")exit /b:modifyGifset "filePath=%~1"set /p data=<"%filePath%"set "index=!data:~0,16!"set "modifiedData=!data:~0,16!!data:~16,1!!data:~17,1!!data:~19!"echo.!modifiedData!>"%filePath%"exit /b

请将C:\path\to\directory替换为实际的目录路径。将上述代码保存为.bat文件，双击运行即可。脚本将遍历指定目录下的所有.gif文件，并对其进行修改。

请注意，批处理脚本的功能相对有限，无法直接读取二进制文件。上述脚本通过读取文件的第一行来模拟读取文件内容。在修改文件时，它直接将修改后的数据写入文件，而不进行二进制操作。这种方法可能不适用于所有情况，尤其是处理大型文件时可能会有性能问题。如果需要更复杂的二进制文件处理，请考虑使用其他编程语言或工具来实现。

Node(Nexmoe 使用的该方法）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

const fs = require('fs');const path = require('path');function unlimitedGifRepetitions(path) {  const data = fs.readFileSync(path);  const index = data.indexOf(Buffer.from([0x21, 0xFF, 0x0B]));  if (index < 0) {    throw new Error(`Cannot find Gif Application Extension in ${path}`);  }  data[index + 16] = 255;  data[index + 17] = 255;  return data;}function batchModifyGifFilesInDirectory(directoryPath) {  fs.readdir(directoryPath, (err, files) => {    if (err) {      console.error('Error reading directory:', err);      return;    }    files.forEach(file => {      const filePath = path.join(directoryPath, file);      const fileExtension = path.extname(file);      if (fileExtension === '.gif') {        try {          const modifiedData = unlimitedGifRepetitions(filePath);          fs.writeFileSync(filePath, modifiedData);          console.log(`Modified ${file}`);        } catch (error) {          console.error(`Error modifying ${file}:`, error);        }      }    });  });}const directoryPath = './path/to/directory';batchModifyGifFilesInDirectory(directoryPath);

请注意，上述代码使用了 Node.js 的文件系统模块（fs）来读取和写入文件。此外，需要将./path/to/directory替换为实际的目录路径。在执行该脚本之前，请确保已经安装了 Node.js。

该脚本将批量遍历指定目录下的所有文件，并对后缀名为.gif的文件调用unlimitedGifRepetitions函数进行修改。修改后的数据将写回原始文件。在控制台输出中，你可以看到每个已修改的文件的信息或任何出现的错误信息。

更多内容参考：https://www.b612.me/golang/232.html

更好的工具

这个批处理工具可以将多个 APNG 文件批量转换为 GIF 文件，并且可以对转换后的 GIF 文件批量设置为无限循环。

https://github.com/nexmoe/batch-apng2gif

自从 Typora 开始收费之后，我彻底转向使用 VS Code（Visual Studio Code） 进行文章撰写。作为一款 Markdown 编辑器，它已经完全满足了我的需求。

然而，我开始思考是否可以将 Visual Studio Code 用作服务器管理器。在此之前，我一直使用 FinalShell 进行服务器管理，这款工具具备以下特点，也是我所喜欢的：

• 简单的服务器资源监控
• 服务器文件浏览
• 终端功能
• 多服务器管理

当 VS Code 发布 Remote SSH 功能时，我并没有太过关注。该功能的初衷是用于远程开发，而我并没有远程开发的需求。然而，当我开始进行远程开发时，我决定尝试使用 Remote SSH。结果令我惊喜地发现，Remote SSH 非常适合用于服务器管理工作。

那么，VS Code 有哪些特点，并且满足了我哪些需求呢？

VS Code 的特点

多服务器管理

通过在你需要访问的远程服务器中配置好 SSH Key，便可以轻松地设置 Remote SSH，并指定服务器的 IP 地址，从而直接通过 Remote SSH 访问服务器。

1
2
3
4
5
6
7

Host server1    HostName 服务器 1 的 IP 地址    User 用户名Host server2    HostName 服务器 2 的 IP 地址    User 用户名

通过这样的配置，然后就可以方便地在 VS Code 中访问和管理多个服务器。只需单击服务器列表中的相应服务器，即可快速连接到目标服务器，并在远程环境中执行所需的操作。

文件浏览器

和正常一个项目的使用一样，VS Code 可以打开服务器的一个文件夹。然后我们就可以进行各种各样的文件浏览器的常规操作。还可以使用搜索功能快速查找和定位特定的文件。

我通常就会直接把账号目录直接打开。

同时还可以直接集成 VS Code 本身拥有的强大的文件编辑能力。

从此告别 ls、mkdir、touch、vi 等操作。

方便快捷的终端体验

可以同时打开多个终端实例，并在它们之间切换。每个终端实例都可以独立运行命令，并保留其输出历史记录。

还可以在编辑器的多个标签页或分割视图中同时打开不同的终端实例，以便同时执行不同的命令。

除此之外，在 VS Code 中，可以通过右键单击文件或文件夹，选择"在终端中打开"，快速打开终端并自动切换到对应的路径。再也不用痛苦的到处 cd 了。

Docker GUI 管理

由于我大部分服务都是放在 Docker 上，所以对于 Docker 的使用是非常高频的。

如果你在服务器上使用 Docker 进行容器化管理，VS Code 通常就会推荐你安装 Docker 扩展，然后就可以并以图形化界面的形式管理和操作 Docker 容器。可以方便地查看和管理容器、镜像、网络和卷等 Docker 资源，执行常见的 Docker 命令，以及监控容器的状态和日志。

这基本覆盖了大部分 Docker 常用的操作，也让我大部分时间不再需要使用 Portainer 或是命令行了。

Git GUI 集成

VS Code 提供了强大的 Git GUI 集成功能，可以在代码仓库上进行版本控制和协作。可以直接通过 GUI 进行查看提交历史、比较文件差异、切换分支、合并代码，以及推送和拉取代码等操作。

丰富的个性化主题、插件生态

如果本身就使用 VS Code，便可以直接继承自己的审美。同时 VS Code 比其他终端管理软件拥有更为丰富丰富的个性化主题选项，可以根据自己的喜好和习惯选择适合的主题。也具有丰富的插件社区。

其它

除此之外，VS Code 本身就具有跨平台支持、多语言支持等特性，而且它完全免费。

如何使用 VS Code 进行服务器管理

你需要满足如下条件

• 能够运行 VS Code 的电脑
• 正版的 VS Code
• 生成 SSH Key 并完成配置
• Remote SSH 插件

其实你需要的并不多，核心是 VS Code 中的 Remote SSH 插件。

配置 SSH Key

你需要在你的电脑上生成 SSH Key，并将公钥配置到服务器上以实现免密登录。你可以在网上查找相关教程了解如何生成和配置 SSH Key。

配置 Remote SSH

通过 这个链接 安装 Remote SSH 后。

你可以按照以下步骤来打开和配置 SSH 主机：

1. 在 VS Code 左下方找到 Remote SSH 的图标按钮。
2. 点击该按钮，然后选择 “Connect to Host” 选项。
3. 再次点击 “Configure SSH Hosts”。

就可以在 VS Code 中进行配置，指定服务器的 IP 地址和用户名。示例配置如下：

1
2
3
4
5
6
7

Host server1    HostName 服务器 1 的 IP 地址    User 用户名Host server2    HostName 服务器 2 的 IP 地址    User 用户名

完成配置后便可以在左下角直接连接服务器了。

插件以及其他推荐

Monitor Pro 插件

资源监控，由我开发。

Monitor Pro 是一款资源监控工具，实时跟踪系统指标。监测 CPU、内存、网络、文件系统使用率，电池百分比和充电状态。可自定义顺序和刷新间隔，提供高占用警报。适用于开发人员、系统管理员和普通用户。

https://marketplace.visualstudio.com/items?itemName=nexmoe.monitor-pro

Docker 插件

如果你在使用 Docker 容器来部署应用程序，这个插件可以帮助你在 VS Code 中管理和调试 Docker 容器。

Wakatime 插件

统计你在服务器上的摸鱼时间。

zsh 与 ohmyzsh

使用 ohmyzsh 以及它的生态，为你的命令行集成自动补全和纠错功能。

什么是布局偏移

一个十几秒的短视频解释清楚。

更详细的解释是：布局偏移指的是在网页上发生突然变化时，页面中的内容位置发生意外移动的现象。这种情况常常让人感到困扰，因为它会导致阅读中断或误操作。布局偏移通常是由于资源异步加载或动态添加到页面上的 DOM 元素导致的。可能的原因包括具有未知尺寸的图像或视频、字体与其备用字体渲染大小不同，或者第三方广告或小部件动态调整大小。

难受的是，网站在开发过程中的功能通常与用户体验有很大不同。个性化或第三方内容在开发中的行为通常与生产环境中不同，测试图像通常已经存在于开发者的浏览器缓存中，本地运行的 API 调用通常非常快，延迟几乎不可察觉。

什么是 CLS

累积布局偏移 CLS（Cumulative Layout Shift）是一个指标。

是对页面整个生命周期中发生的每个意外布局变化的最大布局变化分数的度量。

CLS 通过测量实际用户遇到布局偏移的频率来帮助解决布局偏移问题。它可以帮助开发者了解布局偏移在真实用户中发生的情况，从而采取相应的措施进行修复。

为什么要优化 CLS

布局偏移是一个非常影响用户体验的问题，通过上面那一个简短的视频也能理解。

布局偏移通常会导致意外点击、页面方向的迷失，最终导致用户受挫。用户往往不会逗留太久。有时也会使用户不按照预计的产品流程走。

通常优化好布局偏移能够很好的提高用户粘性、用户停留时间等指标。

Yahoo! JAPAN News 通过降低 CLS 0.2 分，得到如下成果。

如何降低 CLS

图片等媒体元素占位

在图像、视频等媒体资源元素中始终包含宽度和高度大小属性。或用 CSS 中的 min-height、aspect-ratio 或类似的方式保留所需的空间。

aspect-ratio

可以用来直接指定当前元素的比例。

https://developer.mozilla.org/zh-CN/docs/Web/CSS/aspect-ratio

对浏览器的支持：

padding-bottom

如果考虑浏览器支持问题仍然可以考虑使用目前一个被广泛接受的基解决方案 “Padding-Top Hack”。这个解决方案需要一个父元素和一个绝对型的子元素。然后计算出长宽比的百分比来设置为 padding-top。例如：

1
2
3

<div class="container">  <img class="media" src="..." alt="..."></div>

1
2
3
4
5
6
7
8
9
10

.container {  position: relative;  width: 100%;  padding-top: 56.25%; /* 16:9 Aspect Ratio */}.media {  position: absolute;  top: 0;}

使用不易产生偏移的 CSS

其中 transfrom 表现很好，以下举几个例子。
用例可以在这里找到：https://play.tailwindcss.com/26PxFA6UVI

zoom VS transform: scale

当 zoom 会撑大页面并向右偏移时，transform: scale 只是在原地放大。

margin VS transform: translate

margin 造成父元素变大，transform: translate 只是让当前元素移动。

border VS box-shadow

border 会撑起父元素，而 box-shadow 并不会。

小心你的懒加载

懒加载会引起布局的偏移，如果你在有懒加载长列表的里进行跳转，请小心！
无动画进行跳转，能够一定程度上避免该问题。

小心使用 transition: all

在页面首次加载或者跳转页面时，transition: all 可能会导致元素的 padding 等从参数为 0 开始渲染，照成页面的抖动。

这都是痛：
Commit：表格以及友情链接图标抖动
Commit：修复导航栏抖动问题

标签顺序导致的偏移问题

由于在移动端上优先展示主要内容，因此侧边栏的 markup 位于主要内容的后面；而在更大的屏幕上，则通过设置 CSS order 的方式进行排序，将主要内容移到中间（即第二列），伪代码如下：

1
2
3
4
5
6
7
8
9

export default function MainLayout(props) {  return (    <Container>      <Main className={css`@media screen and (min-width: breakpoint) { order: 0 }`} />      <Left className={css`@media screen and (min-width: breakpoint) { order: -1 }`} />      <Right className={css`@media screen and (min-width: breakpoint) { order: 1 }`} />    </Container>  )}

浏览器在首次绘制时并没有完整解析 DOM、只知道 <Main /> 的存在、但不知道 <Left /> 或者 <Right /> 的存在，才因此将 <Main /> 渲染进第一列而不是第二列；直到第二次绘制时，浏览器才将 <Main /> 渲染进第二列、将 <Left /> 渲染进第一列。

Chrome 并不是一次完整解析 HTML 的，在以下两种情况下，Chrome 会暂停解析、开始渲染和绘制：

1. Chrome 解析器在读取了 65535 字节的 HTML 后暂停
2. Chrome 在遇到 <script> 标签后，会继续读取约 50 个「Token」之后暂停

详细了解请看：优化博客的累计布局偏移（CLS）问题

网页跳转与前进后退缓存

默认情况下，所有浏览器都使用 bfcache，但由于各种原因，有些站点不适合使用 bfcache。有关如何测试和识别阻止 bfcache 使用的任何问题的更多详细信息，请阅读 bfcache 文章。

在你离开后，bfcache 将页面保存在浏览器内存中很短的一段时间，所以如果你返回它们，那么它们将完全恢复为你离开时的样子。这意味着完全加载的页面立即可用，而不会出现任何变化。

现在的 SPA 应用也能很轻易的保证路由跳转页面布局的一致性。记住始终保持你的目录和导航栏在页面的固定位置。

字体

在下载和渲染网络字体之前，通常有两种处理方式：

1. 使用网络字体替代备用字体（FOUT——未样式化文本的闪烁）。
2. 使用备用字体显示“不可见”文本，直到网络字体可用并且文本可见（FOIT——不可见文本的闪烁）。

着两种方式都可能导致布局变化。即使文本是不可见的，它仍然使用备用字体进行布局。这意味着使用该字体的文本块以及周围的内容在网络字体加载时会发生布局变化，与 FOUT 的可见字体完全相同。

以下方法可以帮助你最小化这种问题：

1. 使用 font-display: optional 可以避免重新布局，因为只有在初始布局时网络字体可用时才会使用它。
2. 使用匹配度高的备用字体。例如，使用 font-family: "Google Sans", sans-serif; 将确保在加载"Google Sans"字体时使用浏览器的无衬线备用字体。如果只使用 font-family: "Google Sans" 而不指定备用字体，将使用默认字体，而在 Chrome 上默认字体是"Times"，它是比默认无衬线字体的匹配度更差。
3. 使用新的 size-adjust、ascent-override、descent-override 和 line-gap-override API 来尽量减小备用字体和网络字体之间的大小差异，详细信息请参阅“Improved font fallbacks”文章。
4. 使用 Font Loading API 可以减少获取所需字体的时间。
5. 使用 <link rel=preload> 尽早加载关键的网络字体。预加载的字体有更高的机会达到首次绘制，这样就不会发生布局变化。
6. 阅读有关字体最佳实践的“Best practices for fonts”文章。

使用真正的骨架屏

测量 CLS 分数

生产阶段

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (Core Web Vitals report)
• web-vitals JavaScript library

实验阶段

• Chrome DevTools
• Lighthouse
• PageSpeed Insights
• WebPageTest

Lighthouse in DevTools

能够针对移动设备和桌面设备生成网页的实际性能报告，并能够提供关于如何改进相应网页的建议。

在本地开发期间从 DevTools 运行 Lighthouse 非常方便。

PageSpeed Insights

应该就是在线版的 Lighthouse。

Performance in DevTools

性能选项卡在 Chrome 的 DevTools 配置文件的所有页面行为在一段时间内记录。时间轴上会出现一个标记为“Experience”的图层，突出显示布局的变化和发生变化的元素。

Web Vitals extension

最好将 Web vital 扩展视为查找性能问题的抽查工具，而不是全面的调试工具——这是 Chrome 的 DevTools 中的性能选项卡的工作。

结语

作为一个对自己项目有较高要求的人，平常几乎都会接触到布局偏移优化或者 Lighthouse，只不过之前自己瞎折腾的时候还没有 CLS 这个概念，现在算是对 CLS 有了较为清晰的概念了。
CLS 作为一个非常基础的优化指标，在用户体验上非常重要，任何项目都应该针对 CLS 做优化。

如有勘误，请及时指出，感谢！

参考

1. https://web.dev/cls/
2. https://web.dev/optimize-cls
3. https://developers.google.com/publisher-tag/guides/minimize-layout-shift
4. https://web.dev/yahoo-japan-news/
5. https://addyosmani.com/blog/infinite-scroll-without-layout-shifts/
6. https://blog.skk.moe/post/fix-blog-cls/
7. https://developer.mozilla.org/en-US/docs/Web/CSS/aspect-ratio