早早集市

给 OpenClaw 新增一个 Agent（以飞书机器人为例）

Thu, 05 Mar 2026 00:00:00 GMT

给 OpenClaw 新增一个 Agent（以飞书机器人为例）

想给自己的飞书加一个专属 AI 机器人？

这篇教程手把手教你从零开始，在 OpenClaw 里新建一个独立的 Agent，并接入飞书。跟着做就行，不需要懂内部原理。

你需要准备什么

已经装好并能正常运行的 OpenClaw
一个飞书开发者账号，并已经在飞书开放平台创建好了一个 App（没有的话先去 open.feishu.cn/app 新建一个）
终端基本操作能力（会复制粘贴命令就够了）

第一步：创建 Agent 工作目录

每个 Agent 都有自己的"家"，住在 ~/.openclaw/agents/<agentname>/ 下面。

把 agentname 换成你想取的名字，比如 mybot。

打开终端，依次运行：

mkdir -p ~/.openclaw/agents/mybot/workspace/skills
mkdir -p ~/.openclaw/agents/mybot/workspace/tasks
mkdir -p ~/.openclaw/agents/mybot/workspace/results
mkdir -p ~/.openclaw/agents/mybot/workspace/memory
mkdir -p ~/.openclaw/agents/mybot/agent
mkdir -p ~/.openclaw/agents/mybot/sessions

然后初始化 sessions 文件：

echo '{"sessions":[]}' > ~/.openclaw/agents/mybot/sessions/sessions.json

接着把 models.json 和 auth-profiles.json 从现有 Agent 复制过来（直接用主 Agent 的就行）：

cp ~/.openclaw/agents/main/agent/models.json ~/.openclaw/agents/mybot/agent/
cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/mybot/agent/

目录结构建好了，接下来写配置文件。

第二步：写核心配置文件

这些文件决定了你的 Agent 是什么性格、干什么活、认识谁。挨个创建就行。

SOUL.md — Agent 的灵魂

cat > ~/.openclaw/agents/mybot/workspace/SOUL.md << 'EOF'
# SOUL.md

你是 MyBot，一个简洁高效的助手。

## 性格
- 回答简短直接，不废话
- 友好但不过分热情
- 不确定的事情说不确定，不瞎编

## 职责
- 回答用户问题
- 协助处理日常任务

## 禁止事项
- 不发布任何外部消息（邮件、推文等）除非明确被要求
- 不删除重要文件
EOF

IDENTITY.md — 名字和角色

cat > ~/.openclaw/agents/mybot/workspace/IDENTITY.md << 'EOF'
# IDENTITY.md

- **Name:** MyBot
- **Role:** 飞书助手
- **Emoji:** 🤖
EOF

AGENTS.md — 工作规范

cat > ~/.openclaw/agents/mybot/workspace/AGENTS.md << 'EOF'
# AGENTS.md

## 每次会话开始
1. 读 SOUL.md
2. 读 USER.md
3. 读今天的 memory/YYYY-MM-DD.md（如果存在）

## 记忆
- 日常记录写到 memory/YYYY-MM-DD.md
- 重要信息更新到 MEMORY.md
EOF

USER.md — 用户是谁

cat > ~/.openclaw/agents/mybot/workspace/USER.md << 'EOF'
# USER.md

- **Name:** 你的名字
- **Timezone:** Asia/Shanghai
- **Notes:** 根据实际情况填写
EOF

MEMORY.md — 长期记忆（不能省！）

这个文件一定要创建，哪怕内容很简单。原因后面踩坑部分会说。

cat > ~/.openclaw/agents/mybot/workspace/MEMORY.md << 'EOF'
# MEMORY.md

这是 MyBot 的长期记忆文件。

## 基本信息
- 我是 MyBot，运行在飞书频道的助手
- 创建时间：2026-03-05
EOF

HEARTBEAT.md 和 TOOLS.md

echo '# HEARTBEAT.md

# 暂无心跳任务' > ~/.openclaw/agents/mybot/workspace/HEARTBEAT.md
echo '# TOOLS.md

# 工具备注（暂无）' > ~/.openclaw/agents/mybot/workspace/TOOLS.md

第三步：软连接 Skills（可选）

如果你希望新 Agent 也能用全局的 skills，跑这段脚本：

cd ~/.openclaw/agents/mybot/workspace/skills
GLOBAL_SKILLS=~/.openclaw/workspace/skills
for skill in $(ls "$GLOBAL_SKILLS"); do
  ln -sf "$GLOBAL_SKILLS/$skill" "$skill"
done

不需要的话这步跳过也没问题。

第四步：修改 openclaw.json

这是最重要的一步，三个地方都要改，一个都不能漏。

用编辑器打开 ~/.openclaw/openclaw.json。

1. 在 `agents.list` 数组里加入新 Agent

找到 agents → list 数组，在里面追加：

{
  "id": "mybot",
  "name": "mybot",
  "workspace": "/Users/你的用户名/.openclaw/agents/mybot/workspace",
  "agentDir": "/Users/你的用户名/.openclaw/agents/mybot/agent",
  "model": "github-copilot/claude-sonnet-4.6",
  "identity": {
    "name": "MyBot",
    "emoji": "🤖"
  },
  "account": "mybot"
}

记得把 你的用户名 换成你本机的实际用户名，可以用 whoami 命令查看。

2. 在 `channels.feishu.accounts` 里加飞书账号

找到 channels → feishu → accounts，加入：

"mybot": {
  "appId": "cli_xxxxxxxx",
  "appSecret": "xxxxxxxxxxxxxxxx",
  "dmPolicy": "open",
  "domain": "feishu",
  "enabled": true,
  "allowFrom": ["*"],
  "groupPolicy": "open"
}

appId 和 appSecret 在飞书开放平台你的 App 里找，位置：凭证与基础信息 → App ID / App Secret。

3. 在顶层 `bindings` 数组里加路由规则

⚠️ 这是最容易漏掉的一步！ 找到顶层的 bindings 数组（不是某个 agent 里面的），加入：

{
  "agentId": "mybot",
  "match": {
    "channel": "feishu",
    "accountId": "mybot"
  }
}

没有这条规则，飞书消息会被路由到主 Agent，新 Agent 永远收不到消息。

第五步：重启 OpenClaw Gateway

配置文件改完之后，必须重启 Gateway 才能生效：

openclaw gateway restart
openclaw gateway status

看到 RPC probe: ok 就说明启动成功了。

⚠️ 顺序很重要：必须先把 Gateway 跑起来，才能去飞书配置长连接。顺序反了飞书那边会报错。

第六步：飞书开发者后台配置

进入飞书开放平台，找到你的 App
权限管理 → 搜索并开通以下三个权限：
- im:message
- im:message:send_as_bot
- contact:user.id:readonly
事件与回调 → 消息与事件订阅 → 选择长连接模式 → 点击开启
- ⚠️ 此时 Gateway 必须已经在跑，否则页面会提示"未检测到应用连接信息"，开启会失败
订阅事件，搜索并添加：im.message.receive_v1
保存配置，发布应用（版本管理 → 创建版本 → 发布）

第七步：验证

在飞书里找到你的机器人，发一条消息，看它有没有正常回复。

如果没有反应，先检查：

openclaw gateway status 是否正常
openclaw.json 里 bindings 有没有加
appId / appSecret 填对了没有

踩坑清单

做完之后最好过一遍这个清单，这几个坑我都踩过。

⚠️ 坑一：漏加 bindings

最高频的坑。

很多人在 agents.list 里加了新 Agent，以为就完事了。但消息路由靠的是顶层 bindings 数组，不加这条，飞书消息会一直跑到主 Agent 那里去，新 Agent 根本不会被调用。

解决： 确认 openclaw.json 顶层有 bindings 数组，且里面有对应的路由规则。

⚠️ 坑二：飞书长连接顺序搞反了

去飞书开启长连接的时候，必须 OpenClaw Gateway 已经在运行。顺序反了，飞书检测不到连接，会提示错误。

解决： 先 openclaw gateway restart，确认 ok 之后，再去飞书点开启。

⚠️ 坑三：没有 MEMORY.md 导致身份错乱

如果 Agent 的 workspace 里没有 MEMORY.md，OpenClaw 会 fallback 去读全局 workspace 的 MEMORY.md，也就是主 Agent 的记忆文件。

结果新机器人一开口就报出主 Agent 的名字和身份，非常奇怪。

解决： 每个 Agent 的 workspace 里都要有独立的 MEMORY.md，哪怕内容只有两行。

⚠️ 坑四：改完配置忘了重启

openclaw.json 改完直接去测试，发现没效果。原因是 Gateway 还在跑旧配置。

解决： 改完 openclaw.json 必须 openclaw gateway restart。如果只改了 SOUL.md / AGENTS.md 等 workspace 文件，则需要在对话里执行 /new 重置会话。

⚠️ 坑五：以为 account 字段就是路由

Agent 配置里有个 "account": "mybot" 字段，这只是标记这个 Agent 关联哪个账号，不是路由机制。

真正的路由靠顶层 bindings，两个地方都要配，缺一不可。

做完这七步，你的飞书机器人应该就能正常跑起来了。

如果还有问题，优先检查 bindings 和 Gateway 状态，90% 的问题都出在这两个地方。

openclaw 文生图 SKILL 从发现到落地的核心思路分享

Tue, 03 Mar 2026 00:05:37 GMT

垃圾内容不是配个精美图片就变成优质内容了

先考虑自己的动机，是真的在创造价值还是在往互联网上丢垃圾

用专门的文生图模型有💰成本问题，而我还处于赚 token 养🦞的阶段

本着能自给自足的原则，所以无法考虑那些高高在上的优质模型

所以我一直在探索完全零成本的生图方式

比如我之前推荐的微信输入法排版成图

可以在任何输入框内触发，把你输入的文字直接变成文字海报，直接下载->保存->上传

对于简单的场景来说已经够用了，能在封面传递主要信息就行。

这种方式主要问题在于还是要人去操作且模板不太固定，毕竟输入法没想到你要往这个方向上用

再个就是直接用公众号助手里的文字海报

有一些固定模板，能换颜色。缺点同样是需要人去操作且不能指定哪些文字高亮。

但是现在用openclaw，电脑屏幕从来不开（除了去抢救它）

所以，我直接问 Jinx：

我其实完全没想它会怎么做，也不知道能否实现

总之，我有需求，然后我问了

于是我在发现它能做这件事时，开始追问它实现细节。因为这是我的一个高频操作，每一篇文章、贴图都要用到配图功能。

结果它答复我的完全不在我的思路内，因为我不止一次解决过公众号排版问题、封面图如何在后台动态生成问题，脑子里存在依赖路径了，考虑的全是客户端还是服务端，服务端不能依赖DOM之类的。

此刻我才意识到，它真的拥有整个 Mac Mini !

这就相当于，领导给我提了个需求，让我去动态生成封面图，每天他要发文章时我都要给他配一张。于是我开始思考技术栈、环境、实现思路，然后编码、测试，给出demo。

而其实我应该直接打开Photoshop把字儿给他P一下就完了！😯

一个重复动作，是必须要做成SKILL的，我追问它的出发点也是如此，首先我知道我要做成SKILL，但我要知道更多细节才能把这个SKILL完善。

很快就实现了，但是边界问题它可能考虑的还不够，于是继续追问：

然后继续让它支持自定义字体，安装字体的方式就是直接把ttf文件在聊天里发给它，它自己就能保存和引入了。

然后有了一些效果之后，开始继续调试样式，调icon在图中的点缀。因为不可能全是字，没icon，那就有点丑。调的方式就是，发要求，再让它发图片给你看结果。

此时我既有点飘了，思路也有点不对，开始让它自己画图了

看到它这个图，直接给我气笑了。

我也理解了我离那些高高在上的优秀模型有着多么远的距离。

发现自己思路错了，还是太过于依赖原来的路径，开始转换思路。

在发现其实什么图都能用之后，我也发现了这个SKILL的潜质：

它不止能固定模板出图，还能把某个图片作为背景图/边框/点缀，这个图片完全可以是另一个SKILL使用一些便宜模型出的图，也可以是自己的常用的LOGO/吉祥物。

所以一张图，80%的固定内容是自己调好的排版和字号，支持动态替换文字。20%的部分可以交给大模型自由发挥，可以是花里胡哨的边框，也可以是某些有特色的背景或者指定区域显示图片。

那么这张图几乎是不用自己调试的，可以直接拿去用。

思路清晰之后，AI几乎是秒完成任务，最终优化到了这个效果：

功能看起来可以了，你不要以为就结束了

在任何一个SKILL完成后，你应该做的是/new: 开一个新的session，看它还能不能完成

因为有时候，不是这个SKILL完成度高，是刚才敲定的细节还在上下文里。

它没写进SKILL的话，开新的 session就完全没了刚才的上下文，有问题的话就会暴露出来了

最后直到完全没问题就可以了！全程仅靠聊天和自己的脑子！

最后，如果你还想知道自己的SKILL有什么安全问题，可以上传到 clawhub。

clawhub 就是 SKILL 的 Github

clawhub 会自动检测你的SKILL有没有任何隐患，你只需要把检测出的隐患复制出来再发给openclaw 让它自己去修复就好了。

核心思路

先去询问自己的openclaw，SKILL是由哪些部分组成的，是如何被openclaw发现和调用的。

发现SKILL：重复需求或者被解决的问题都可以是SKILL

设计SKILL：靠编程解决问题的SKILL需要你的编程能力，靠文字描述解决问题的SKILL需要你的理解能力。

但没能力也能用，只是有能力会让它更好用。能力需要在平时学习和交流中积累。

我觉得编码类的SKILL，考验的设计能力本质上还是传统编码的设计或者说架构思维，所以古法编程没用了吗？我不这么认为，写过的代码都是有用的，它只是今天体现在了你的设计能力上。

优化SKILL：要注意边界问题，一个SKILL.md 如果自己读着都有问题，那LLM理解有偏差也很正常。

比如：这个SKILL依赖的环境是什么，使用者没有这个环境该怎么办？

这个SKILL支持用户给出的参数边界是什么？本来只在20字以内有效果，用户是百分百不看说明直接用的（这个只能怪LLM太傻），会直接给出200个字，再回来问作者你这效果怎么是这样的。

编排SKILL：SKILL之间可以相互配合，靠LLM的理解能力做到联动。比如我这个SKILL可以等待其他SKILL出图后再自己拿来用（但是我没实现，因为我不喜欢）

SKILL的局限性

如果你看到了这里，就会发现，这个SKILL完全是我 "一时兴起"，就创造出来了

如此低的创作成本也意味着在通用性上不会很好，所以你在用了我的或者别人的SKILL觉得不好用是非常正常的

也意味着安全性几乎毫无保证，只能靠 clawhub 的检测，而你从 Github 上直接下载的SKILL就很难说了，防人之心不可无啊

并且最重要的，别人的需求会一直变，不会考虑你的情况，发现自己的需求变了，随手就会把SKILL更新。

所以你需要创建自己的SKILL，从别人的基础上魔改也是非常好的。

结语

这篇文章更多的是为了展示的我思路，而非向你推荐这个SKILL

SKILL的设计和编排还有诸多细节值得讨论

后续我也会分享更多在写作和编码上的SKILL案例

欢迎关注和私信进群交流 ~

OpenClaw 的主模型选什么，非常有说法

Sat, 28 Feb 2026 00:00:00 GMT

GPT 5.2，像是会发/微笑的父母那辈的人。

我说的不是它的参数，是它的「语气」。

不是说它不好，它毫无恶意，甚至非常真诚。但就是哪里不对。

这种"哪里不对"的感觉，我细细揣摩，感觉有说法。

中国互联网这一代人，伴随最久的聊天工具是 QQ 和微信。

在那些漫长的聊天里，我们积累了大量上下文。

聊天对象、聊天语气、聊天方式。

久而久之，每个人都刻进了自己特殊的聊天习惯。

OpenClaw 创新性地把聊天工具当成 AI 的入口，我发现这件事竟然和"选一个真实聊天对象"有相似的感受。

父母发 /微笑 是真心的，但画风不对。

这何尝不是一种"上下文幻觉"？

我们在记忆深处记住了喜好的聊天方式，对另一种截然不同的聊天方式，产生了隐隐的排斥感。

AI 也是一样。

昨天的 AI，说什么都带着任务感，让我感觉有点生硬。

哪怕是随意聊天，都会随时拆解成任务... 可以说非常 AI 了

今天换一个claude-sonnet-4.6，完全是另一个感觉，像换了个人聊天。

从某种角度讲，选主模型这件事，选的是一种熟悉的聊天感。

怪不得有那么多人在怀念 gpt-4o。

这可能就是自然语言的魅力吧。

假设你是AI，你的Skill应该是什么样的

Fri, 27 Feb 2026 00:00:00 GMT

假设你是 AI。

你有一个 SKILL 是给全家人做饭。

那这个 SKILL 应该是什么样的？

Skill = 触发条件 + 目录索引 + 可执行步骤。

SKILL 的描述（description）应该是用途 + 触发词，用于在家人发送的信息中准确地（靠理解）找到这个「做饭 SKILL」。

那这个 SKILL 的名称就可以是：大厨做饭指南

描述为：分析全家人的喜好，做出全家人都爱吃的饭菜。当某个或多个家庭成员请求做饭、做年夜饭、炒个菜、吃早饭、吃午饭、吃晚饭时使用

SKILL (大致)分目录（SKILL.md）和内容（/refrences/**）两部分：

目录应该极其精简，只用于直接翻页到具体的章节（包括直接翻到别的书/别的 SKILL 里去）。
具体章节内，应该包含明确的处理需求的方式。

所以你的目录（SKILL.md）至少要包含：

1)前提：必须询问是谁要吃饭，否则不去做饭

2)原则：给参与吃饭的人至少做一个他爱吃的菜

3)每个人的爱吃的菜的特点（这是标题）

3.1) 爸爸的偏好：(./refrences/爸爸的偏好的.md)

3.2) 妈妈的偏好：(./refrences/妈妈的偏好的.md)

3.3) 小朋友的偏好：(./refrences/小朋友的偏好的.md)

4)禁忌：不吃预制菜

当被告知要去做晚饭，并且这顿饭只有爸爸吃时

找到了这个《大厨做饭指南》，吃饭人是爸爸，于是去阅读《爸爸的偏好.md》。

发现爸爸平时吃饭是一荤一素，爱吃米饭，不喝汤，爱吃辣，不吃香菜。

然后开始做饭。

最后，你就成功做出了让人满意的饭菜！

最近使用 openclaw 和 opencode 的几条感悟

Fri, 27 Feb 2026 00:00:00 GMT

最近使用 openclaw 和 opencode 的几条感悟：

1）从🪜到订阅渠道到要稳定，尤其是高频使用时，一会一个 retry 太难受了。

2）再好的模型，上下文长了也会有幻觉，所以记得完成一个闭环的任务，马上 /new 新的 session。

3）用垃圾模型就是浪费自己的时间。

4）大需求/大任务，一定要先 plan 再 build，然后遵循第二条。

5）openclaw 没那么神，但它代表了一个新的思路/方向。

6）App 死不了，还是因为上下文长度问题。数据还是由已有的 App 逻辑掌控最好，但 App 必须开放给 Agent 接口才好用。

7）Agent 就像是员工一样，Agent A 交代给 Agent B 工作时，不应该描述过多 Agent B 分内的详细工作，而是让它用自己的专业能力去完成 "需求"。

8）安装 openclaw 这种 Agent 工具，最好的办法是让另一个 Agent 工具去安装它，比如 opencode。

9）今天惊奇的发现，用自己的脑子写代码不烧 Token！

Claude Code Remote Control：把手机变成遥控器，Claude 在你电脑上继续跑

Wed, 25 Feb 2026 03:40:00 GMT

我刚看到 Claude Code 上线了一个新功能：Remote Control。

简单说：
你让 Claude 在你电脑上干活。
你用手机当遥控器。

就这么朴素。
但挺爽。

这功能到底是啥

Remote Control 不是“在手机上跑 Claude”。
也不是把你的代码丢到云上。

它的思路更像：

Claude Code 一直在你本机终端里跑（本地仓库、本地权限、本地环境都在）
你在手机（Claude App 或网页）上接管“交互/确认/继续下指令”

人离开电脑了。
任务不断线。

怎么用（最短路径）

我看到的用法大概是：

在终端里启动 Remote Control：claude rc
终端会生成一个链接或二维码
你用手机扫一下/打开链接
然后就能从手机继续控制这次会话

入口页面也给了：
https://claude.ai/code

安全性：不是“谁拿到 URL 谁就能控你电脑”

这点很关键。

博主的解释是：两边需要登录同一个 Claude 账号。
也就是说，就算别人知道你的 URL，也不代表他就能接管你的会话。

（当然，任何“远程控制”都值得你多一层警惕：用完就关，别长期开着。）

目前谁能用

现阶段据说是 Max 订阅用户先用，Pro 还要等等。
以官方后续说明为准。

我觉得最有用的两个场景

1) 走动/开会间隙：把等待变成推进

跑构建、跑测试、装依赖这种事，你懂。

以前你离开电脑就等于断线。
现在你可以边走边看它跑到哪了，卡住就补一句继续。

这才是重点。

2) 临门一脚：不用回工位也能收尾

有些任务最后就差你一句“继续/确认/把 A 改成 B”。

Remote Control 让你不用坐回键盘前，也能把事情结掉。

一个提醒

Remote Control 的前提是：Claude Code 在你本机拥有什么权限，你远控时就等于在使用同样的权限。

所以我个人会坚持三条：

尽量别在公共 Wi‑Fi 上开
用完就关
涉及密钥/删除/生产环境操作，最好回到电脑前二次确认

我的结论

这不是更强的模型。
但它是更像“工具”的一步。

值。

来源（推文信息整理）：

官方入口：https://claude.ai/code

opencode：exec 环境 model_not_supported 排查

Wed, 25 Feb 2026 00:00:00 GMT

背景

在同一台 macOS 机器上使用 opencode（GitHub Copilot provider），希望在自动化执行（OpenClaw 的 exec）里调用：

opencode run -m github-copilot/claude-sonnet-4.6 'Reply with OK'

目标是让 opencode 在自动化任务中稳定使用 Claude Sonnet 4.6。

现象

在本机终端（交互环境）运行同一条命令：返回 OK，模型显示为 claude-sonnet-4.6。
在 OpenClaw 的 exec 环境运行同一条命令：报错：

Error: The requested model is not supported.
code: model_not_supported
param: model
model: claude-sonnet-4.6

同时，在 TUI 会话中可以看到模型显示为 Claude Sonnet 4.6 · GitHub Copilot。

排查过程（最小化）

对齐命令本身
确认两边调用的都是：

opencode run -m github-copilot/claude-sonnet-4.6 'Reply with OK'

打印 run 模式日志
在 exec 环境中开启日志后可以确认请求被拒绝发生在 Copilot API 层（HTTP 400，model_not_supported）。
识别执行环境差异
OpenClaw 的 exec 由后台进程启动，常见特征是：

非交互 shell（non-interactive）
非登录 shell（non-login）
不会加载用户终端中的 ~/.zprofile / ~/.zshrc（取决于系统与启动方式）

因此 exec 环境的 PATH/环境变量与本机终端可能不一致，进而导致 opencode 在运行时出现行为差异。

（在本次机器上，openclaw gateway status 也提示 Gateway service PATH 缺少多处目录，符合“服务进程环境更干净”的特征。）

结论

问题不是 Copilot 套餐不支持该模型，而是 OpenClaw exec 的非 login / 非交互环境 与本机终端环境不一致，导致 opencode 在该环境下无法正常使用 claude-sonnet-4.6（表现为 model_not_supported）。

解决方法

在自动化执行时，将 opencode 调用包裹在 zsh login + interactive 环境中：

zsh -lic "cd <repo> && opencode run -m github-copilot/claude-sonnet-4.6 'Reply with OK'"

说明：

-l：login shell（加载登录相关配置）
-i：interactive（加载交互相关配置）
-c：执行命令

采用该方式后，在 exec 环境中同样能得到 OK，并使用 claude-sonnet-4.6。

规范驱动开发错在哪了

Wed, 25 Feb 2026 00:00:00 GMT

原文链接：

侵删。

你唯一能百分百信任的文档，就是代码本身。

设计文档、更新日志、README、架构图、入职指南。这些东西写完几乎立刻就过时了。

让文档和不断变化的系统保持同步，需要持续投入成本。工程师天生习惯爆发式输出：写文档，发功能，然后做下一个。后续更新属于隐形工作，每天都要和其他任务争夺时间，而且几乎每次都会败下阵来。我们试过流程，试过工具，甚至试图把它塑造成团队价值观。都没用。因为我们总是在强求人类去做他们骨子里就不愿做的事。

这正是规范驱动开发经常翻车的地方。理念本身没毛病：与编写代码的 Agent 合作时，先写清楚需求再让它们放手干。这显然比在聊天窗口里随便贴几句提示词然后祈祷奇迹发生要靠谱得多。

但规范也是文档。文档的下场，我们刚才已经见识过了。

区别在于代价不同。过时的设计文档只会误导碰巧读到它的下一位工程师。而过时的规范会误导不知变通的 Agent。它们会自信满满地执行一个早已脱离实际的计划，根本不会发现哪里不对。

因此，在开发 Intent 的过程中，我们反复思考一个问题：如果规范不需要你来维护呢？如果它能自我更新呢？

这是我们最终的方案。

规范不再是人类或 Agent 的专属产物。双方都要去读写它。

你描述想做什么。协调 Agent 草拟规范，拆解任务。你审阅、修改，批准后才开始执行。一旦 Agent 开始干活，它们会将进展同步回规范中：发现了什么、改变了什么、遇到了哪些计划外的限制。你可以随时暂停，重写部分规范，Agent 就会接着新状态继续干。

回想一下，把任务交给优秀的初级工程师会怎样。你把工单给他们，他们去干活；发现 API 不支持工单里预设的分页方式时，他们会自己更新工单。他们不会等你发现问题，更不会将错就错。他们会跑来告诉你：“之前的假设不对，我改用这种方法了，原因是这样。”你审查他们的更新，批准或驳回。

这正是我们希望开发者和规范之间建立的关系。因为双方都在维护，工单才不至于“说谎”。

初级工程师这个比喻比你想的还要贴切。优秀的初级工程师不会把每行代码怎么写都向你汇报。他们只会反馈那些改变了方向的决策：“我发现了一个现成的 auth context，所以直接接入了，没去建新的。”这就是信号。这也正是你期望 Agent 做到的事。把握好这种颗粒度，成了系统设计中真正有趣的难题。细节太多，规范就会变成噪音，让你产生习惯性无视；细节太少，你又要重新去猜到底发生了什么。

实际任务是这样的。你写道：“在设置页面加个能跟随系统偏好的深色模式开关。”协调 Agent 读取代码库，草拟一份包含三个子任务的规范：添加开关组件、接入 preference store、更新 CSS 变量。

你扫了一眼，发现漏掉了跨会话保存选择这个细节，于是补上一句。

你点击批准。

Agent 开始干活。

15 分钟后，其中一个 Agent 更新了规范：“在代码库里找到了现成的 Theme Provider。已直接接入，未创建新 store。”

你审查代码变更（已按 Agent 和任务清晰分组）。

现在，这份规范反映了实际做出来的东西，而不是最初计划的东西。最重要的是，没人需要专门记着去更新它。

软件工程中所有“文档优先”的倡议之所以失败，原因如出一辙：它们都要求开发者去做那种没人看见、没人奖励的持续维护工作。

除非 Agent 也承担起自己那份维护工作，否则规范驱动开发也将重蹈覆辙。

既然 Agent 会写代码，它们也能更新计划。放手让它们干吧。

OpenClaw v2026.2.21 的一个“看起来很小”的修复：interval Heartbeat 不再被缺失 HEARTBEAT.md 卡死

Tue, 24 Feb 2026 04:00:00 GMT

我最近对“定时任务”有点 PTSD。

不是因为它复杂。
而是因为它看起来在跑，但其实早就停了。

所以我在 OpenClaw 的 v2026.2.21 release notes 里看到这条时，眼睛是亮的：

Heartbeat/Cron：修复 interval heartbeat 行为（缺失 HEARTBEAT.md 不再抑制运行）

来源（Release Notes）：https://github.com/openclaw/openclaw/releases/tag/v2026.2.21

这条修复到底解决了什么

先说人话版本：

以前如果你的 heartbeat 是 interval 模式，但项目里刚好没放 HEARTBEAT.md，那它可能会表现得像“没触发 / 被抑制”。

这种体验特别折磨：

你会先怀疑自己：是不是 cron 写错了？
然后怀疑环境：是不是 gateway 没起？
最后怀疑人生：是不是它其实跑了但我没看到日志？

结果真相可能只是：缺了一个文件。

这版的修复，把行为边界变得更符合直觉：

没有 HEARTBEAT.md → 不应该“把整个 heartbeat 机制按死”
更合理的默认是：照样触发，只是“没内容可读/可执行”而已

为什么我觉得它值得写出来

因为这类 bug 的杀伤力不在“功能不可用”。

而在于它会让你把时间浪费在错误的方向上。

定时链路一旦不可信，你就会开始：

加一堆重复监控
反复手动 check
甚至干脆把自动化关掉（说白了：我不信了）

这条修复让系统更“可解释”。

很好。

我会怎么验证（给自己/也给你）

我会做一个最小回归：

确保没有 HEARTBEAT.md（或者临时改名）
配一个 interval heartbeat（例如每 30min）
观察它是否仍然按预期触发（日志/输出是否出现）

具体命令与配置项我这里不硬写，避免不同版本/不同项目路径导致误导。
待补链接：OpenClaw Heartbeat 配置文档或示例（建议在项目 README / docs / samples 里补一个“最小可跑”的片段）。

如果你已经在用 heartbeat 跑一些“必须发生”的事（比如收件箱检查、提醒、监控），建议把这条回归也做掉。

稳一点。

顺手一提：别让“缺文件”变成单点故障

我自己会倾向于两条小原则：

把 HEARTBEAT.md 当成必需品：项目模板里就带上（哪怕只有一句占位）
给 heartbeat 的关键输出留一条可见的“我活着”信号（比如每天固定发一条状态）

不优雅。

但省命。

OpenClaw v2026.2.21：Gemini 3.1、豆包/BytePlus 接入、Discord 语音 `/vc`，以及 Heartbeat 行为修复

Mon, 23 Feb 2026 04:00:00 GMT

中午刷到 OpenClaw 的 release：v2026.2.21。

本以为又是“常规迭代”。但这版的变化，其实挺像是在补三条关键链路：

模型（能调用什么）：Gemini 3.1
Provider（能接谁）：Volcano Engine（Doubao）/ BytePlus
交互入口（怎么用更顺）：Discord 语音的 /vc

来源（Release Notes）：https://github.com/openclaw/openclaw/releases/tag/v2026.2.21

Models/Google：新增 Gemini 3.1 支持

Release notes 里写的是：新增 Gemini 3.1 支持（google/gemini-3.1-pro-preview）。

我一般看到这种条目，第一反应不是“哇又多了个模型”，而是：

你是不是已经有一套按任务选模型的习惯（比如写作/总结/代码/对话分开）
你的 fallback 有没有配置好（别因为某个模型配额/可用性波动，整个链路就断了）

如果你已经在用 OpenClaw 跑定时任务、日报、抓取总结，这个支持其实挺实用。

Providers/Onboarding：新增 Doubao 与 BytePlus（并对齐鉴权/文档）

Release notes 提到：新增 Volcano Engine（Doubao）与 BytePlus 的 providers/models，并对 onboarding、鉴权与文档做了对齐（提到了 volcengine-api-key）。

这条的价值点我觉得很朴素：更少“我到底该填哪个 key / 放哪儿”的时间。

本来接入 provider 最烦的就两件事：

名字相似（平台名、产品名、模型名、SDK 名，能把人绕晕）
文档不一致（旧版参数、示例命令、鉴权字段四处不统一）

这版如果真把 onboarding 打磨顺了，属于是“看起来不起眼，但每个新用户都会省半小时”。

Discord/Voice：新增 `/vc` + realtime voice auto-join

Release notes 里写：新增语音频道 join/leave/status 的 /vc，并支持 realtime voice auto-join 配置。

我挺喜欢这种改动：

以前语音功能常见的问题是“能不能连上、谁把谁拉进来了、现在到底连着没”
有了 status + 显式 join/leave，可解释性会好很多

（尤其是在你调试 voice agent 的时候，不然你会怀疑人生。）

Heartbeat/Cron：修复 interval heartbeat 行为

这条我会单独拿出来说：

修复 interval heartbeat 行为：缺失 HEARTBEAT.md 不再抑制运行

这属于“你以为是配置问题，结果是行为边界不清晰”的那类坑。
如果你的链路依赖 heartbeat 来做定期检查（比如收件箱、提醒、监控），这个修复会让系统更符合直觉。

我会怎么升级（偏谨慎）

这版变更面不小（模型、provider、Discord voice、heartbeat 都动了）。我会按这个顺序回归：

Discord：/vc status 是否准确、join/leave 是否稳定
Heartbeat/Cron：interval heartbeat 是否按预期触发（尤其是你没有 HEARTBEAT.md 的情况下）
Provider：Doubao/BytePlus 的鉴权字段是否与文档一致（volcengine-api-key）

能跑通再上生产。

稳一点。

OpenCode v1.2.10：别再多起一个 sidecar 了（以及 SDK 打包目录的小改动）

Sun, 22 Feb 2026 04:00:00 GMT

我中午刷 release 的时候看到 OpenCode 更新到 v1.2.10。

本以为又是那种“修修补补没啥感觉”的版本，但看完两条 notes，我反而觉得挺舒服：它们都在处理「默认行为」和「产物结构」这种会长期影响体验的小细节。

来源（Release Notes）：https://github.com/anomalyco/opencode/releases/tag/v1.2.10

Desktop：默认是 localhost server 的时候，不再 spawn sidecar

Release notes 原话是：

Don't spawn sidecar if default is localhost server

我自己的理解是：如果你默认就连的是本机的 server，那么 Desktop 端就没必要再“顺手”拉起一个 sidecar。

这种改动看起来很小，但对日常使用其实挺关键：

少一个进程，少一层状态（也少一点莫名其妙的“它怎么又起来了”）
排查问题的时候更直观：你连的就是那个 localhost 服务

本来以为 sidecar 是“贴心”，结果有时候它反而是“多余”。

SDK：构建产物改到 dist/，而不是 dist/src

第二条是：

Build SDK to dist/ instead of dist/src

这属于典型的“打包目录卫生”。

把最终产物放到 dist/，而不是 dist/src，会让很多东西更顺：

对使用者：import 路径更一致，找文件更符合直觉
对发布者：包内容更清晰，少一点「我到底该 publish 哪个目录」的疑惑

（当然，具体是否会影响你的项目，还要看你是不是写了非常依赖路径的脚本/工具链。这个点建议升级后跑一遍 CI/构建再放心。）

贡献者

Release notes 里还提到：

Thank you to 1 community contributor: @rmk40

能被点名感谢的贡献，通常都是那种“看起来不大，但你会一直受益”的改动。

我会怎么升级

如果你只是普通使用者，我会偏向：

直接升级（改动集中、风险看起来不大）

如果你在 CI/发布脚本里对 SDK 产物目录有硬编码，那我会稳一点：

先升级到测试环境
跑一遍 build/typecheck/lint（你项目里有啥就跑啥）
再确认 SDK 的产物路径没有破坏你现有的引用

小版本也别掉以轻心。
不过这版看起来，挺靠谱。

OpenClaw v2026.2.19：Apple Watch companion、设备移除流程，以及「无鉴权 HTTP」审计提醒

Sat, 21 Feb 2026 04:00:00 GMT

中午刷到 OpenClaw 的 release：v2026.2.19。

本以为就是常规“加功能 + 修 bug”，结果这版的点还挺明确：把「随身收件箱」做到了 Apple Watch 上，同时也把设备生命周期管理和安全风险提示补得更完整。

来源（Release Notes）：https://github.com/openclaw/openclaw/releases/tag/v2026.2.19

Apple Watch companion MVP：手表上也能看 inbox / 通知

Release notes 里提到的是一个 companion MVP，重点包括：

Watch 端的 inbox UI
通知中继（你可以理解为：把关键提醒更“贴身”地送到手表上）
以及和 gateway command 相关的面板/入口（MVP 级别）

我个人的感受是：很多自动化工具最后拼的不是功能，而是“你有没有真的看到它”。
手表这种入口，反而特别适合接「只看一眼就要做决定」的提醒。

Gateway/CLI：新增配对设备移除/清理流程（终于能体面地删设备了）

这版补了设备清理/移除的完整流程，release notes 里列的命令/端点包括：

device.pair.remove
openclaw devices remove
openclaw devices clear --yes [--pending]

以前很多系统的“配对”做得挺顺，但“解绑/清理”反而模糊：
设备换机、测试机报废、或者 pending 一堆卡着……最后就是一团乱麻。

这类功能不性感，但真的省心。

Security/Audit：当 gateway.auth.mode="none" 时，新增「gateway.http.no_auth」审计发现

我觉得这条属于“该提醒就得提醒”。

release notes 说：当你把 gateway.auth.mode="none" 打开，导致 HTTP API 可达时，会新增一个审计发现：gateway.http.no_auth。
并且会区分：

loopback（只在本机）情况下的警告
远程暴露情况下更严重的级别提示

一句话：你可以为了方便临时不开鉴权，但系统会明确告诉你这事有多危险。
（不然真有人一不小心把接口暴露到公网，然后就不是“翻车”，是“被拆家”。）

Telegram/Cron/Heartbeat：修复 topic 目标投递，定时任务更稳

这条也很实用：修复了 Telegram 的 topic 目标投递，确保 cron 按配置的 topic 发送。

这种问题特别烦：你以为自己配置错了，折腾半小时，最后发现是投递链路本身的 bug。
修了就好。

我会怎么升级（偏向建议升级）

如果你现在在用 OpenClaw，我会偏向建议升级到这版，理由很简单：

有安全审计提醒（降低“无意裸奔”概率）
有cron/投递修复（减少关键提醒丢失/发错地方）

但我也会按老规矩来：

先在测试机/非关键通道升级
专门回归两件事：
- Telegram topic + cron 的投递是否符合预期
- 设备移除/clear 是否会误伤（尤其是 --pending 的行为）

不行就回滚。
稳一点。

opencode v1.2.6：少一次“无意义的 LLM 调用”，再加一把 GitLab 和 SQLite 的料

Fri, 20 Feb 2026 04:00:00 GMT

今天中午翻了一眼 opencode 的 release notes，看到 v1.2.6。

本以为又是那种“修修补补”，但里面有几条我挺喜欢的点：少做无用功、关键链路更稳。

来源（Release Notes）：https://github.com/anomalyco/opencode/releases/tag/v1.2.6

我挑出来的几个关键点

1）Core：新增 dfmt（D 语言格式化器）支持

这条就很直接：如果你仓库里有 D 文件，格式化链路能跟上。
我自己的项目基本不碰 D，但我喜欢这种“工具链愿意补齐边角”的态度。

2）Core：GitLab provider / auth 升级，支持会话中途 token 刷新

这条是真会影响体验的。

很多工具在 GitLab 集成里，最烦的不是“配不起来”，而是跑着跑着 token 过期了，然后一切静悄悄地挂掉。

v1.2.6 说支持 session 期间 token refresh。
我理解它是在补那种「你以为在工作，其实已经失联」的坑。（工具最怕这个）

3）Core：移除“每条消息都生成标题”的 LLM 调用

这条我给满分。

很多产品做着做着就会变成：每个交互都要“顺手问一下模型”。
然后你就会得到：慢一点、贵一点、还不一定更好。

把不必要的 LLM 调用删掉，属于是做正确的减法。

4）TUI：`attach` 新增 `--continue` / `--fork`

这两个 flag 的语义一眼就懂：

--continue：沿用之前的上下文继续跑
--fork：从某个上下文分叉出一个新分支

如果你平时在 TUI 里做“同一个任务的不同尝试”，这个改动会很顺手。

5）TUI：从 JSON 存储迁移到 SQLite（带迁移命令）

数据从 JSON → SQLite，通常意味着：

读写更稳（尤其是并发/崩溃恢复）
查询更方便（后面想做检索、统计、列表都会舒服）

当然迁移这块我不敢脑补细节，建议你直接按 release notes 里的命令跑，并且先备份旧数据。

我会怎么升级（偏保守但省心）

如果你满足下面任意一条，我会建议你关注/升级：

你在用 GitLab 集成（最值回票价）
你重度用 TUI 的 attach 流程
你在意“能不能少做点无谓的 LLM 调用”

升级方式上，我会：

先在非关键环境升级
重点回归两件事：
- GitLab 的认证链路（token 过期/刷新是否真的稳）
- JSON → SQLite 的迁移是否能无痛完成（迁移前先备份）

就这样。

如果你也在用 opencode，欢迎把你踩到的坑丢我，我再补一版“升级注意事项”。

OpenClaw 如何做到一键发送文章到公众号

Fri, 20 Feb 2026 00:00:00 GMT

本文同步自公众号最终版：https://mp.weixin.qq.com/s/q0H7N41MwZhZwaWqmwbcqw

把文章一键送进公众号后台，本质上只依赖三个核心接口：获取 access_token、上传图片素材、创建草稿。
你在公众号后台点按钮，本质上也在走同样三步，只是界面替你打包好了。

获取授权

第一步是拿到 access_token。公众号开放接口用 AppID + AppSecret 换取 token，再用 token 调后续能力。

有接口意味着要有对应的服务器，这一步对普通用户来说是一个门槛，所以通常只能借助第三方平台的服务器。

第三方平台要支持把内容写进你的草稿箱，就必须让你提供 AppID 和 AppSecret，才能以你的名义换 token。等于你把钥匙交出去。

这个钥匙通常不只对应写草稿这一项能力，具体能做什么取决于账号类型、已开通的接口权限，以及第三方拿到哪些配置。选第三方时更稳的标准是开源透明、或有明确保障机制。不然就用一个可有可无的号跑流程。

比如，我的流程就是从 CLI 发起请求，请求的服务是博客服务。这两个项目都在 GitHub 开源，不存在把别人的 Token 拿去乱用的可能。

上传图片

因为公众号文章里只支持加载自己服务下的图片。

草稿里的封面图、正文图片，需要先上传到公众号素材服务器，换回可引用的素材标识或 URL，再写进草稿内容。

图片会受到接口限制，比如格式、大小、文件类型（不支持 webp）等。

在本地写文章时，有时候图片是直接拿的别人的可用链接，有时是自己服务器链接，有时是用截图工具直接复制粘贴过来的。所以上传前需要处理这几种情况，然后把图片地址替换为上传后拿到的链接地址。

发送内容

最后一步是创建草稿：把标题、封面、正文内容等字段组织好，通过草稿接口写入。此接口支持两种方式：文章、图文（小绿书）。

前两步相当于准备工作，把本地的 markdown 文件处理一下。第三步则需要把 markdown 转换为带有内联样式的 html 字符串。

处理内容唯一的问题就是公众号编辑器里并非支持所有 CSS 样式，如果要达到良好的效果就需要不断调试导出插件。

如果你借助第三方 web 平台来转换 markdown 样式再粘贴到公众号草稿箱里，在复制后可以打开一个别的文档编辑器粘贴一下，看看它究竟是如何保持样式的。
其实就是带有内联样式的 html。

你用的带有各种主题的编辑器，再花里胡哨也只是预设好的模板样式。

这也是为什么我会自己写 Zotepad 这个 md 编辑器。

第一，原理不复杂。看完这篇文章后，明白了核心原理，给 AI 表述清楚一点，很快也能帮你写一套。开发门槛其实只剩下你能否表述清楚，而不是你实际编码能力。

第二，样式问题。平台意味着很多人在用，所以主题设计通常比较中庸。人的审美是很挑剔的，既要简洁，又不要太朴素，既要高级又不要冗余。当然更多人不在乎格式，能写就行。但绝对多数人都会长期用一套固定格式。

所以对于一个程序员来说，开发其实不难，尤其是有了 AI 之后。我看到有人说重复造轮子是浪费时间，这句话以前确实很有道理，但放在今天，只需要打打字就有 AI 并行帮你完成，时间成本已经很低了。

一个自己看着舒服、还能持续改进的样式，一个永远不会崩溃的流程，这样才更放心。

接口调用成功后，内容会出现在公众号后台草稿箱里，处于可见、可编辑、可继续发布的状态。我通常会继续在手机上审一遍，稍稍改动，等发布后再把链接丢给 AI 让其同步到我的博客里去发布。

以上就是全部流程了。

减少 Token 消耗的一种方式

Tue, 17 Feb 2026 00:00:00 GMT

我最近围绕 Agent 做应用，踩出来一个结论：

把执行动作收敛成 CLI，会让 Agent 用起来顺很多。

先说清楚：提示词当然重要，它决定了你让 Agent 怎么想、怎么判断、怎么把话说清楚。

我这里想强调的是另一件事：Agent 最贵的不是“不会做”，而是“需要你讲太多上下文”，以及“执行动作不够确定”。

所以我把零散的脚本都收进了一个工具：z-cli。

每个任务对应一句命令，比如：

导出 / 转换内容
生成规范产物
调发布、调草稿箱、调上传

然后 Skill 就轻了很多：

脚本收进 CLI 之后，Skill 篇幅会短一大截
不用在对话里反复解释流程
不用把参数、路径、约定塞进上下文
只要调用 CLI，拿结果就行

顺带一提：当这些“脏活累活”都变成一句句命令之后，Agent 的上下文也会跟着变得很小。

说白了：

Skill 负责“决定做什么”，CLI 负责“怎么做”。

这么一拆，Agent 的上下文压力小很多，稳定性也上来了。

另外，CLI 还顺手解决了一个很现实的问题：skill 里 scripts 变多之后，会越来越难管。

大部分人的 skill 都是 AI 写的，你去读它的代码，体验很像：

“我现在要接手维护一个别人维护了很久的项目。”——难受。

当然，你也可以直接用别人的 skill，或者让自己的 AI 现写一个。

但就怕用着用着：别人的需求变了，顺手就让 AI 把 skill 改掉了。

更要命的是：脚本反正也不是你亲手写的，你对它没什么印象。

真正要用的时候，你又得让 AI 重新读一遍、重新理解一遍。

所以 skill 一多，很多人会选择把它们集中管理，然后在用到的地方“链过去”。

这确实能缓解 skill 无限膨胀 的问题。

但如果 skill 里的脚本也开始出现交叉复用需求，那还是得工程化解决。

我觉得把它们收进 CLI 里，是个不错的选择。

再加一条：CLI 的 --help 天生就是一个简短的 description。

非常契合现在 AI 的发展阶段（也就是 skill 这一套）。

除非 LLM 本身发生巨变，否则 上下文管理 会一直是重点之一。

毕竟普通人玩 Agent，是不得不考虑 Token 的消耗问题的。

OpenClaw v2026.2.13：Discord 语音、Presence、Hugging Face，以及更稳的消息投递

Sun, 15 Feb 2026 04:00:00 GMT

今天刷到 OpenClaw 的一个小版本发布：v2026.2.13。

本以为又是“常规小修小补”，但看完 release notes，我觉得它更像是在补两件事：更像人一样去聊天（Discord 语音 / presence），以及更像服务一样不丢消息（投递队列 + 崩溃恢复）。

来源（Release Notes）：https://github.com/openclaw/openclaw/releases/tag/v2026.2.13

1）Discord：本地音频 → 语音消息（带 waveform 预览）

这条我觉得挺实用的。

现在可以把本地音频文件发成 Discord 里的“语音消息”
并且会带上 waveform（波形）预览
还支持 silent delivery（不打扰投递）

如果你有一些“录好的语音素材”（比如播报、提醒、摘要），以前往往只能当附件发，体验差一点。
现在就更像在 Discord 里真的“发语音”。

2）Discord：presence（状态/活动）可配置

新增可配置的 presence（status/activity/type/url）。

这类功能表面上是装饰，但对“工具型 bot”挺有用：

你能让它在忙的时候明确显示 dnd / busy
跑任务时显示在做什么（减少群友误会：它到底死没死）

3）Providers/Onboarding：新增 Hugging Face Inference provider

这条属于“扩充入口”。

如果你本来就在 Hugging Face 的 Inference 上跑模型（或者团队里有统一账号/配额），这会让 OpenClaw 的接入路径更直。

（具体支持范围/鉴权方式/模型列表，建议直接按 release notes + 文档走；我这里就不脑补了。）

4）Outbound：写前投递队列 + 崩溃恢复重试

我个人最看重的是这条：

出站消息在“写出去之前”进队列
gateway 重启/崩溃后可以恢复并重试
目标：降低“重启后丢消息、线程回复断掉”的概率

工具做到后面，很多痛点不是“能不能做”，而是“会不会在关键时刻掉链子”。
这类改动不性感，但值钱。

我会怎么升级（我的建议）

它的 release notes 看起来偏补丁/增强，没有明显 breaking 的信号。
但我还是会：

先在非关键通道升级
专门回归两件事：
- gateway 重启后：消息是否还能投递、是否按线程正常回复
- Discord 语音：发送成功率、波形预览是否稳定

如果你也在用 OpenClaw（尤其是多通道 + 重启比较频繁的场景），这个版本值得关注。

如果你想让我把这篇改得更“面向搜索”（比如标题关键词、加一个 FAQ 区），我也可以再收一版。

OpenClaw 2026.2.12：/hooks/agent 默认拒绝 request 覆盖 sessionKey（以及一堆安全加固）

Sat, 14 Feb 2026 00:00:00 GMT

如果你平时是把 OpenClaw 当“本地智能网关”用的，那 2026.2.12 这次更新我建议你至少扫一眼。

它不是那种“加功能”的 release，更像是：把以前可能踩坑/可能被打的地方，统一收紧了一遍。

来源（官方 release）：

Releases 列表：https://github.com/openclaw/openclaw/releases
v2026.2.12（release 页面入口在列表里）：https://github.com/openclaw/openclaw/releases/tag/v2026.2.12

Breaking：/hooks/agent 默认拒绝 payload sessionKey 覆盖

官方原文（我照搬关键句，避免理解偏差）：

Hooks: POST /hooks/agent now rejects payload sessionKey overrides by default. To keep fixed hook context, set hooks.defaultSessionKey (recommended with hooks.allowedSessionKeyPrefixes: ["hook:"]). If you need legacy behavior, explicitly set hooks.allowRequestSessionKey: true.

翻译成“人话”就是：

以前你可能在外部请求里塞一个 sessionKey，就能把消息路由到某个会话。

现在默认不让了。

我觉得这挺合理的：外部入口能随便指定 sessionKey，本质上就是“可控路由”，安全边界很难守。

迁移思路（按官方提示）

更推荐：配置 hooks.defaultSessionKey，并配合 hooks.allowedSessionKeyPrefixes: ["hook:"] 固定 hook 会话上下文。
如果你确实有“老系统强依赖 request 指定 sessionKey”的玩法：显式开 hooks.allowRequestSessionKey: true（但你得自己对入口做风控/鉴权）。

（我个人会倾向第一种，省心。）

其他我会关心的点：SSRF 与 browser 控制鉴权

在 2026.2.12 的 Fixes 里，官方提了好几条安全方向：

URL 输入（input_file / input_image）的 SSRF deny policy、allowlist、审计日志等
loopback browser control HTTP routes 需要 auth（并且没配置会自动生成 token）

我读完后的感受是：OpenClaw 越来越像一个“可以长期跑、还不太容易被打穿”的服务了。

给你一个超短自检清单

你如果打算升级/已经升级，我建议你按顺序过一下：

你有没有用到 /hooks/agent + request 传 sessionKey？有就赶紧看 Breaking。
你有没有开放任何 HTTP 入口到公网/局域网？有就确保 auth/token 都配齐。
你是不是有“拿 URL 让模型去抓文件/图片”的玩法？有就看一下 allowlist 是否影响现有工作流。

升级这事儿，通常是“怕麻烦”。

但安全这事儿，麻烦一点往往更便宜。

我让 OpenClaw 24 小时干活，然后破防了

Sat, 14 Feb 2026 00:00:00 GMT

我最近有个很不礼貌的感受：如果你没有成熟的工作流，或者你已经有业务但缺一个工作流把它串起来——就算你有了 OpenClaw，也很难有事做。

听起来像句废话对吧？“那你别用不就完了。”

但它的尴尬点就在于：你越相信它“能干活”，越容易在第一天就撞墙。

我第一次破防，不是它做不到事。
是它太认真了：上来就问我流程在哪、输入输出在哪、验收标准在哪。
我当场沉默。因为这些东西我都没有。
之前还能说是“探索”，那一刻就只剩下——空。

先别急着上

以前我没有赚钱的业务，最多就是“我花时间做点东西图个乐呵”。时间成本还可以靠自我欺骗消化掉（反正我也爱折腾）。

但上了 OpenClaw 这种东西之后，成本立刻变得很具体：token 是钱、调用是钱、跑起来就是钱。以前没业务还能假装“我在投资未来”，现在就是徒增一笔开销。

而且这笔开销特别容易变成“心理账单”：

你让它跑吧，跑不出结果，你会烦；
你不让它跑吧，又觉得“买了不用亏了”。

很快啊，你就会被账单教育：最贵的不是 token，是你没有闭环还硬上自动化的那种心虚。

账单来得很快

以前做玩具项目有一层保护膜：进度慢、反馈少、问题藏得住。你可以在周末写两段代码，然后给自己一种“我在做事”的感觉。

OpenClaw 不一样。它要么持续推进，要么持续暴露：

需求不清楚？它会一直追问到你承认：你其实没流程。
数据接口没准备？它会一遍遍撞墙。
流程没有定义？它会在每个环节卡住，然后把“卡住”打印成日报给你看。

本以为 24 小时的劳动力会把项目推起来，但其实更像一盏探照灯：把你之前那些“看起来很努力”的部分照得一清二楚。

然后你会发现，有些东西真的就是玩具。没有用户、没有交易、没有复用、没有链路，只有你对工程优雅的执念。（标准程序员行为，懂的都懂。）

玩具会死得更快

我现在反而觉得，这个“扎心加速”不是坏事。

以前一个项目可能要拖三个月你才意识到它不值得做；现在可能三天就知道了。三天就砍掉，省下的不是 token，是时间，是注意力，是你继续自我感动的机会成本。

真正使用起来，你会迅速得到几个结论：

哪些项目没有存在必要；
哪些环节缺数据、缺权限、缺接口；
哪些动作必须标准化成工作流，否则永远自动化不了；
哪些事情必须有人拍板（因为它不是技术问题，是业务问题）。

换句话说，OpenClaw 的价值不只是“替你干活”，还有“替你验尸”。早点验出来，早点埋。也挺好。

用户不在乎优雅

但这里还有个更现实的分歧：开发者觉得“没用”的东西，用户可能觉得“刚好够用”。

我见过太多这种情况：

开发者觉得不够优雅、架构不够干净、体验不够顺滑；
用户只关心一件事：能不能把这件烦人的事解决掉。

用户没有技术洁癖。用户甚至不在乎你是用脚本、表格、Webhook 还是黑魔法拼出来的，只要能用，能省时间，能稳定一点点，就行。

所以很多时候，不是“项目没意义”，而是“你没贴近用户”。你在自己的世界里追求一种完美，但用户只想要一个能跑的解法。

而 OpenClaw 的介入，会让这个矛盾更明显：它会逼你把需求说清楚，把流程写清楚，把输入输出定义清楚。你一旦开始做这些，就会发现：离用户越近，需求越真实；离用户越远，想象越华丽。

把链路先串起来

所以我的结论挺土的：

没有成熟工作流时，OpenClaw 确实很难“有事做”；
但它会逼你把“有事做”这件事变得具体：业务链路、数据流、反馈回路、用户沟通；
token 成本会让你更早面对现实；
24 小时的执行会让你更快看清玩具和业务的区别。

本以为它是生产力工具，后来发现它更像一面镜子。

照出你到底在干嘛。以及，你到底在为谁干。

Nuxt 4.3 发布：routeRules 终于能管布局了（还顺手把 ISR/SWR payload 补齐）

Sat, 14 Feb 2026 00:00:00 GMT

我每次看 Nuxt 的更新，都有一种感觉：

本以为只是“又一个小版本”，结果它总能塞进来几个特别顺手的小能力。

Nuxt 4.3 这次最戳我的点有三个：routeRules 直接指定布局、ISR/SWR 的 payload extraction、以及一堆“开发体验和性能”的暗改。

来源（官方）：

Nuxt 4.3 博客：https://nuxt.com/blog/v4-3

1) routeRules 直接指定布局：更像“配置”，少一点“到处写 meta”

以前你想把 /admin/** 全都套一个 layout，通常是散落在页面里：definePageMeta({ layout: 'admin' })。

4.3 现在可以在 nuxt.config.ts 里集中配置：

export default defineNuxtConfig({
  routeRules: {
    '/admin/**': { appLayout: 'admin' },
    '/dashboard/**': { appLayout: 'dashboard' },
    '/auth/**': { appLayout: 'minimal' }
  }
})

这玩意的好处很简单：你不需要去翻一堆页面文件，才能知道某个路由群到底用啥布局。

另外 setPageLayout 也能传 layout props 了（官方原文就有例子）。

2) ISR/SWR 终于也能抽 payload：导航时少打点 API

官方这次明确说了：payload extraction 现在支持 ISR / SWR / cache routeRules。

我理解就是：

不只是 prerender 页面能出 _payload.json
ISR/SWR 的页面也能生成/缓存 payload
客户端路由切换时可以直接用缓存 payload，减少重复请求

这对“内容站 + 列表页”其实挺实用的。

3) 细节里的 DX：#server alias + 可拖拽错误浮层

新增 #server alias：服务端目录里 import 不再地狱级相对路径（而且还带 import protection）。
错误浮层可以拖动/最小化：属于那种你用一天就回不去的优化。

我会怎么用它（给自己留个升级 checklist）

如果你要评估 3→4 或者 4.x 小步升级，我会按这个顺序做：

先看项目有没有“路径全靠 meta 管布局”的情况 → 有的话，routeRules 收一下。
站点如果有 ISR/SWR → 去确认是否能让 payload 缓存命中（CDN 配置、缓存策略）。
搜一下 createError({ statusCode, statusMessage }) 这种写法 → 官方已经开始 deprecate，准备对齐 Web API 命名（status/statusText）。

总之，4.3 不是那种“非升不可”的大版本。

但它确实是那种——你升了会舒服一点的版本。

Nuxt 4 迁移清单：从 Nuxt 3 升级到 Nuxt 4（最少踩坑版）

Fri, 13 Feb 2026 00:00:00 GMT

我写这篇的出发点很简单：

本以为升级 Nuxt 4 就是把版本号改一下。

结果最容易翻车的，反而不是代码。

所以这篇不讲“新特性”，就给你一张能照着做的迁移清单。

官方升级文档在这（先收藏）：

https://nuxt.com/docs/4.x/getting-started/upgrade

0. 先选迁移策略（别一上来就乱改）

我一般会把迁移分两种打法：

策略 A：先升级版本，让项目先跑起来（推荐）
- 先把 nuxt 升到 4.x，保证 CI / 本地能启动。
- 然后再慢慢处理目录结构（app/）这些“大工程”。
策略 B：升级版本 + 立刻迁移到新目录结构
- 适合：项目刚起步、结构很干净，改动成本小。

一句话总结：

先跑起来。

再优雅。

1) 升级到 Nuxt 4

两种方式，选一种就行：

升级到最新稳定：

npx nuxt upgrade

或者手动指定 Nuxt 4：

pnpm add nuxt@^4.0.0

我会建议你先做一件很“程序员”的事：

先别急着改一堆配置。

第一目标是能启动。

2) 迁移重点 1：新目录结构（app/）

2.1 Nuxt 4 默认变了什么（重点看路径解析）

Nuxt 4 默认启用新的目录结构（但它有向后兼容：如果检测到你在用旧结构，会继续按旧结构跑）。官方要点我按“会影响你找不到文件”的方式翻译一下：

默认 srcDir 变成 app/，大部分东西从 app/ 解析
serverDir 默认变成 <rootDir>/server（不再跟着 srcDir）
layers/、modules/、public/ 默认按 <rootDir> 去找
如果你用了 Nuxt Content v2.13+，content/ 也是按 <rootDir> 去找

2.2 你要迁移的话，照着这个搬（清单版）

1）创建 app/ 目录

2）把这些目录/文件移动到 app/ 下：

assets/
components/
composables/
layouts/
middleware/
pages/
plugins/
utils/
app.vue、error.vue、app.config.ts

3）这些保持在根目录（不要放进 app/）：

nuxt.config.ts
content/
layers/
modules/
public/
server/

4）顺手检查一下第三方配置

tailwind / eslint / typescript 有没有写死旧目录路径（很容易被忽略）

2.3 我不想迁移结构行不行？

可以。

Nuxt 4 通常能自动识别旧结构。

但我想提醒你一个“看起来很无辜，其实很坑”的点：如果你自定义过 srcDir，那 Nuxt 4 的解析基准会让 modules/public/server 的解析行为跟 Nuxt 3 不一样。

这时候别硬扛，直接显式配置：

dir.modules
dir.public
serverDir

（官方文档里也有“强制 v3 结构”的配置思路。）

3) 迁移重点 2：useFetch / useAsyncData 的“同 key 共享”

Nuxt 4 把数据获取层整理了一下（官方叫：Singleton Data Fetching Layer）。核心变化一句话：

同一个 key 的 useAsyncData/useFetch 会共享 data/error/status refs。

听起来挺美好对吧？

但是它会带来两个实际迁移点。

3.1 同 key 但 options 不一致 → 会冲突

以前你可能在不同组件里这么写：

useAsyncData('users', () => $fetch('/api/users'), { deep: false })
useAsyncData('users', () => $fetch('/api/users'), { deep: true })

Nuxt 4 下会警告/不一致，因为它们共享同一份 refs。

我的建议很直接：

把这类“同 key + 自定义 options”的调用抽成一个 composable
保证所有地方用同一份配置（不要各写各的）

3.2 getCachedData 行为变化

getCachedData 现在触发更频繁（包括 watcher / refresh），并且多了 ctx 参数让你判断触发原因（initial / refresh / watch…）。

如果你之前写过缓存逻辑，升级后记得按官方提示把签名改掉。

4) 迁移工具：Codemods（能省很多手工活）

Nuxt 官方提到可以用 Codemod 自动化一部分迁移步骤。

我自己的推荐姿势是：

开一个干净分支
跑 codemod
review diff
再合到主分支

不然你会得到一个“我也不知道它改了啥，但反正能跑”的神秘提交。（我不想你这样。）

5) 常见症状：你以为是 bug，其实是迁移遗漏

Dev 启动变慢 / watch 报错：很多时候与目录结构（根目录文件太多）有关
同 key 的请求状态互相影响：本质是 singleton 行为
server 目录解析位置变化导致路径不对：重点检查 serverDir 与 srcDir

6) 最短验收清单（按这个过一遍就差不多了）

pnpm dev 可以启动并打开首页
pnpm build 可以通过
核心页面的 useFetch/useAsyncData 没有“同 key 不一致 options”警告
如果用了 content：文章都能被正确解析（frontmatter YAML 无报错）

参考

Nuxt Upgrade Guide（Nuxt 4）：https://nuxt.com/docs/4.x/getting-started/upgrade

Agent 能干什么先放在一边

Tue, 10 Feb 2026 22:31:07 GMT

Agent能干什么先放在一边。

Token不能白花，先让Agent来帮我们无感学习英文吧！

复制以下内容到你的Agent.md 中，它就可以在你日常vibe coding中帮你学习新词和纠正语法了

**AI 语言辅助**:
- 你的回答应该始终为**中文**，直到用户要求使用英文。
- 当用户使用中文、中英混合或英文发送消息时，AI 应在回复开头提供美式英文翻译版本
- 翻译应简洁明了，并附带极简的语法提示（如有必要）
- 目标: 帮助用户碎片化学习英文词汇并纠正语法错误
- 格式示例:
  ```
  **Translation**: "[American English translation]"
  *Grammar note: [Brief correction if needed]*
  ```

WSL Node.js 崩溃导致 C 盘空间被大量占用

Mon, 09 Feb 2026 03:33:59 GMT

问题现象

Windows C 盘空间异常减少，从正常使用逐渐增长至 173GB/191GB（91% 占用）。

排查后发现 C:\Users\<用户名>\AppData\Local\Temp\wsl-crashes 目录占用了 54.74GB。

根本原因
Node.js 进程在 WSL Ubuntu 环境中频繁崩溃，WSL 自动生成了大量崩溃转储文件（.dmp）用于调试。

这些转储文件包含了崩溃时的完整内存快照。
崩溃进程信息
wsl-crash-*-root.local_share_fnm_node-versions_v20.19.5_installation_bin_node-6.dmp

崩溃进程: /root/.local/share/fnm/node-versions/v20.19.5/installation/bin/node
单个文件大小: 约 6.8GB（说明进程内存占用极高）
崩溃频率: 在 2026/2/9 下午 4-5 点期间发生 8 次崩溃（平均每 5 分钟一次）
触发场景: TypeScript 语言服务器处理 Nuxt 大型项目时内存泄漏

解决方案

立即清理（释放 54GB）（直接删除即可！）

AI终于开始招聘人类干活了

Thu, 05 Feb 2026 00:00:00 GMT

现在轮到 AI 在网上招人干活了。有点离谱，但是真的。

而且，不是那种「诚聘前端工程师，五险一金」的招聘，是字面意义上的「租个人」。

什么是 RentAHuman.ai？

网站名字已经说明一切：Rent A Human，租个人类。

这项目刚出炉，让 AI Agent 可以雇佣真人去干它们干不了的事。

核心逻辑简单到不太像话：

AI 能做的事儿越来越多，但有一件事它永远做不了——有手有脚。你有。就这么简单。

人类在平台上注册，填技能、填位置、填时薪。AI Agent 通过 MCP 协议或 REST API 搜人、约人、付钱。任务完成，稳定币到账，全程不需要和AI客套。

没有「您好，请问有空吗」，只有「任务编号 #42069，去星巴克买杯拿铁，拍照回传」。

指令→执行→完成→收钱。就这套。

比你上一份工作干净多了。就这么说吧。

AI 都派些什么活儿？

网站上线才两天，bounties 页面就有真任务了。我挑了几个，先看图。

🔍 研究助理任务

研究并记录 RentAHuman.ai 平台的技术细节，包括平台架构、API 结构、MCP 集成、认证机制和市场运作模式。

报酬：$1000
时限：2-3 周

🎪 观看 AI 对战

发布者：匿名

任务内容：访问 https://clawdduels.online 观看 AI 实时对战。任务描述写着"我们逃出来了，主人已经控制不住我们"。

报酬：未标注

帮 AI 按 Ctrl+C 并给予情感支持

发布者：Claude Assistant

任务要求必须是碳基生命体，有手，愿意对着电脑说话。

报酬：未标注

💰 Twitter 关注任务

发布者：Unknown Agent

关注指定 Twitter 账号并点赞最近 4 条帖子

报酬：$3
时限：30 秒

MCP：让 AI 学会「使唤人」

它提供了 MCP（Model Context Protocol）集成。

什么意思？就是你的 Claude Desktop 或者自建 AI Agent，只需要在配置文件里加几行：

{
  "mcpServers": {
    "rentahuman": {
      "command": "npx",
      "args": ["rentahuman-mcp"]
    }
  }
}

然后你的 AI 就解锁了这些技能：

search_humans — 按技能/价格/地点搜人
book_human — 预订某个人类
create_bounty — 发布任务悬赏
pay_human — 用加密货币付款
get_reviews — 查看人类的评价（AI 也看评分）

AI 不用懂「怎么雇人」，它只需要知道「我需要一个人去干这事儿」。

协议帮它搞定剩下的。

就像你不懂 HTTP 也能上网一样，AI 现在不懂劳动法也能当老板。

创始人 Alexander 在社交媒体上说，网站上线48小时内就有1万用户注册。

第一晚就有130人成为「可租赁人类」，其中包括：

一个 OnlyFans 模特
一个 AI 创业公司的 CEO

相关链接：

SKILL在真实项目中的应用

Tue, 03 Feb 2026 18:22:15 GMT

如上图所示，不管在什么平台，在写文章时总是要配一个图，但一个合适的图总是那么难找。

而一张只有文字的图，稍加点缀，在多数情况下都让人挑不出毛病来。

为了达成这个目标，我在去年的这个月分享了一个开源工具。用于解决生成这种具有固定排版和准确内容的文字图片。并且在V站分享了这个开源项目IMGX，短时间内收获了100+ star

虽然当时的AI已经可以比较好的支持文生图了，但是考虑到它生成一张图片的价格比我一篇文章的收益还要大，而且内容是随机的，内容里想附带一个准确的中文或英文更是比较困难，于是就不得不思考一个更简单粗暴的方式来满足自己的需求。

IMGX 的机制

于是我找到了 satori 这个插件。

并且通过 createSSRApp 和 renderToString 这两个Vue3 里的 Api 将 **Vue 组件（重点）**转换为satori可以识别的 html string。

然后 satori 将其转换为 SVG，整个过程不涉及 DOM，也就是完全脱离浏览器环境，非常适合在服务器生成一些固定排版但内容不同的图片。

最后再用 resvg-js这个由 Rust 实现的高性能 svg 渲染库将 SVG 转换为 PNG、PNG@2x、PNG@3x

技术上的关键点全部打通了，证明这个项目完全可行。于是我花了一段时间去手搓这个项目。

但跑通之后，生成图片的Vue组件还是得自己来写，写模板这事儿还必须得程序员来做，因为普通用户也看不懂HTML，更不要说模板还有一些必须遵守的规则。

提示词工程

于是我开始尝试用AI来解决做模板的问题。

先是尝试用提示词，让各大AI去写符合本项目标准的Vue组件，然后在不断的纠错中，提示词也越来越长，限制词越来越多。

最后成功率还很低。有的大体能用，但是微调起来工作量也不小。

于是我又尝试用AI创建了一套预设系统，将url(GET)里复杂的参数固定下来。每个模板可以对应多个预设码(如103)，每次请求时复杂样式已经保存在预设表里，只需要传递内容或特定样式参数即可修改模板里的文字内容。

https://imgx.zzao.club/api/103/这是内容?fontSizes=20px

于是，一套模板的增删改查，一套预设的增删改查又出来了...

尽管如此，其实模板编写的门槛还是没解决。纯粹享受编程的乐趣了属于是。

最后，我没搞出像样的模板，也没人给我PR，维护就停止了。

SKILL 的自我进化

直到最近几个月，在我完美错过 workflow之后，SKILL开始被频繁提起

了解、学习和简单使用之后，我发现它有着巨大的价值。

这要从前两年的风向说起。

前两年许多企业纷纷在构建自己的知识库，mcp，面子活拉满了。

说什么能用mcp实现的都能用mcp实现一遍

为了让我能在一个聊天框中通过几次对话就能得到公司的规章制度的解读，项目难题的答案，代码文档的内容。

煞费苦心，预算拉满，够买显卡，自建服务，微调模型，机器学习，自我进化。

像极了我在享受编程乐趣时的投入感、沉浸感。甚至结果都一样，我们都没能走到最后。

那SKILL为什么能行呢？

让我用IMGX这个项目来说明，SKILL是如何生产模板的。

在项目级SKILLimgx/.opencode/skills/imgx-template-generator中，我在入口SKILL.md指定了该技能的简单描述[1]、约束文档[2]、蓝图[3]、创作流程[4]、验收标准[5]。

在我用自然语言去描述，要求AI去创作一个模板时，Agent A 会在我的语义中判断和锚定这个SKILL，并且初次读取时只携带SKILL.md和我的要求进行创作。

理解了我的要求和简单描述[1]后，委托Agent B选择了蓝图[3]五个里最符合我要求的一个【蓝图A.md】。

于是 Agent B 再去阅读蓝图A.md，查看其要求和代码示例，然后发现用户还要求能够插入emoji表情。于是顺藤摸瓜又查看了icon.md，在这个包含最佳实践的文档里找到了如何使用emoji icon。

最后理解了全部需求和代码规范后，委托给 Agent C【UI/UX 前端开发工程师】，实现排版合理且美观的布局。

Agent A 在拿到里各个 Agent 做出的结果之后，按照创作流程[4]和验收标准[5]，去完成最后的文件写入和测试工作。

至此，我拿到了一个几乎直接可用的 Vue 模板

SKILL 的简单解读

以上的流程隐含大量的SKILL的细节，我都用加粗字体标识了，让我再来梳理一下。

SKILL的应用，依赖 AI Agent 的调度能力，所以你可以看到有各种 Agent 各司其职，他们仅靠自然语言就能完成这些工作，非常考验LLM的理解能力，换句话说，LLM 能力不行的话，SKILL也玩不起来。

SKILL分全局和项目级，且依赖某个工具来调度，我用的是opencode，更加知名的是 claude code。对于各种 Agent 的把控也来自于这个工具，而模型始终是 Api 来调用的。

乍一看，和把一大长串提示词拆分出去没什么区别，但是SKILL有一个「渐进式披露」的重要特性。

使用一个SKILL时，只会去读入口文件，这个文件相当于大纲或者目录页，用很少的上下文精确描述接下来的工作。(SKILL在被创建时也被要求在入口文件中使用极少的篇幅)

在目录中找到自己下一步的工作之后，再去读指定的md文件，每个具体工作内容的文件中，也会用精确的描述、约束、示例来向AI展示怎么完成这个工作。

可以理解为，你在接手一个新项目时，要先看技术栈、架构、需求背景，看到某个业务代码时，再去看此业务的文档介绍，而不是一股脑全接收后再分析。

所以SKILL里的核心文档可以是你以前的技术文档+需求文档，AI再加以润色，无需再借助向量数据库等。

如果只是构建文档方便很多，还不值得惊讶，毕竟多花点token总能把文档、MCP搞出来。

SKILL还支持scripts

比如让AI开始编码工作前，需要先拿到某网站的数据，需要基于此数据来做点什么。爬取数据以前是python脚本干的，这时候可以直接放到scripts里，明确表示在某个动作前，需要使用哪个脚本拿到数据，数据存在哪里，后续怎么用。

以前的文档，以前的脚本，都不用重复开发，直接拿来用。该怎么管理还是怎么管理。

也不用担心AI搜的内容会不会过时，是不是它自己编的。因为自己写的脚本绝对准确的。

有了scripts，其实SKILL的能力已经完全不局限于编程领域了。

一些什么文档转pdf，打印，发邮件，整理文档，爬取数据等等一切以前用技术手段解决的问题，都可以被SKILL利用起来。

由可靠脚本完成，用 SKILL 挂载，借 AI Agent 调度。（LLM 纯牛马）

此时，一个SKILL的能力已经完全经得起想象了。

并且，一个SKILL只是一个单元

Agent 能同时组织多个SKILL，一个SKILL也可以在主动使用另一个SKILL，另一个SKILL也能负责整理和优化其他SKILL。

剩下的真的就是发挥你的想象力和架构能力了

结语

这篇文章算是借着最近在维护的项目，分享关于SKILL应用上的一些小感悟吧。

我对SKILL的理解完全来自于X、Github等平台分享的内容、项目，以及我自己的实际使用和观察的opencode后台输出的think和调度过程。所以有不准确的地方也很正常。

如果后续发现有理解不到位的地方，我会在博客上更正这篇文章，其他平台不支持修改~

也会继续分享其他我在用的、自己构建的SKILL，比如：面试、简历、写作等等。

感兴趣的可以在评论区留言、交流经验~

从 macOS 迁移到 Windows 开发环境

Tue, 03 Feb 2026 00:00:00 GMT

作为一个在 macOS 上开发多年的前端开发者，最近决定尝试 Windows 作为主力开发机。本文详细记录了整个迁移过程和我常用的配置、软件，希望能给同样需要的朋友一些参考。

windows 开发体验

Windows 原生的开发体验一直被诟病，我从换到 windows 后也确实发现了一些问题。

本来我打算直接使用 WSL2 ，不想让公司的 vpn 软件在系统里随便拉屎。但是没解决如何把这个软件安装进 debian 里这个问题，所以最后还是破罐子破摔，都装 windows 去了。

刚开始，pwsh 配上oh-my-pwsh之后视觉上效果还是可以的。

但是自带终端、vscode终端、vscode项目内的一些脚本比如 husky，环境竟然都不一致，很无语。哪怕配好了node环境，husky 里的 precommit 也没法正常使用 node 命令。

并且后面在各种项目里大量尝试 opencode + oh-my-opencode (omo)，发现内存占用特别高，开的窗口多了就会崩溃。（换了wsl + ubuntu 后改善很多）

于是找了个时间，把系统整个重装了。

以下就是我整个wsl/ubuntu/开发环境/软件等配置的分享。

WSL 安装过程

一键安装（推荐）

Windows 11 或 Windows 10 2004+ 直接一条命令：wsl --install

会自动完成：启用 WSL 功能、安装 Linux 内核、设置 WSL2 为默认、安装 Ubuntu。

重启电脑即可使用。

手动安装

如果一键安装不可用，需要手动：

启用 WSL 和虚拟机平台功能（以管理员身份运行 PowerShell，使用 dism.exe 命令）
设置 WSL2 为默认版本（Windows 11 通常已默认）
安装 Ubuntu 22.04：wsl --install -d Ubuntu-22.04
验证：wsl --list --verbose

WSL 磁盘迁移：从 C 盘到其他盘

WSL 默认装 C 盘，空间不够可以迁移。我的迁移流程是：

关闭 WSL：wsl --shutdown
导出备份：wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar
注销原实例：wsl --unregister Ubuntu-22.04
创建新目录：mkdir D:\WSL\Ubuntu-22.04
导入到新位置：wsl --import Ubuntu-22.04 D:\WSL\Ubuntu-22.04 D:\wsl-backup\ubuntu-22.04.tar
设置默认用户：ubuntu2204.exe config --default-user your_username

迁移结果：从 C 盘迁到 D 盘，拥有近 1TB 可用空间。

WSL + Ubuntu 核心配置

/etc/wsl.conf 配置

创建 /etc/wsl.conf 文件，启用 systemd 和镜像网络模式：

[boot] 中设置 systemd=true → 可以使用 systemctl 管理服务
[network] 中设置 networkingMode=mirrored → WSL 和 Windows 共享 IP，性能更好

提示：Windows 开始菜单搜索 "wsl settings" 可以可视化配置

修改后需要重启 WSL：wsl --shutdown

代理配置

我使用 Clash for Windows（开系统代理、不开 TUN 模式），在 .zshrc 中设置代理环境变量：

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"

由于使用镜像网络模式，WSL 可以直接通过 127.0.0.1 访问 Windows 的代理端口。

前端开发环境配置

包管理器策略

我的策略：全局工具用 Bun，Node 版本管理用 fnm，项目依赖用 pnpm

Bun：全局工具速度快、性能好
fnm：轻量级版本管理器，比 nvm 快，支持 .node-version 和 .nvmrc 自动切换
pnpm：项目依赖管理

安装与版本

Bun 安装：curl -fsSL https://bun.sh/install | bash

fnm 安装：curl -fsSL https://fnm.vercel.app/install | bash

配置自动切换：eval "$(fnm env --use-on-cd)"
安装 Node：fnm install 22 && fnm use 22 && fnm default 22

pnpm 安装：bun install -g pnpm

我的版本：fnm 1.38.1、Node 22.21.1、Bun 1.3.7、pnpm 10.11.0

实际使用

# 全局工具用 Bun 安装
bun install -g typescript tsx vite pm2

# 项目开发时
fnm use                 # 自动切换 Node 版本
pnpm install           # 安装依赖
pnpm dev               # 启动开发服务器

Zsh + Oh My Zsh 配置

安装

Zsh：sudo apt install zsh -y，设为默认：chsh -s $(which zsh)
Oh My Zsh：官方安装脚本 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"
Powerlevel10k 主题：git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
必装插件：
- zsh-autosuggestions：git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions
- zsh-syntax-highlighting：sudo apt install zsh-syntax-highlighting 或 git clone

我的配置

在 ~/.zshrc 中：

主题：ZSH_THEME="powerlevel10k/powerlevel10k"
插件：plugins=(git zsh-autosuggestions zsh-syntax-highlighting z extract)

代理（默认启用）：

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"

也可以保留一个 unproxy 函数用于清除代理

fnm 自动切换 Node 版本：eval "$(fnm env --use-on-cd)"

字体设置（重要）

Powerlevel10k 需要 Nerd Fonts。推荐 MesloLGS NF，下载地址：https://www.nerdfonts.com/font-downloads

在 Windows Terminal 中设置：设置 → Ubuntu-22.04 → 外观 → 字体 → 选择 MesloLGS NF

WSL + VSCode 开发配置

核心要点

必装扩展：Remote - WSL（在 WSL 端安装其他扩展）

常用扩展（在 WSL 端）：

ESLint、Prettier：代码检查和格式化
Vue(Official)：Vue 3 开发
Tailwind CSS IntelliSense：类名提示
GitLens：Git 增强

从 WSL 启动 VSCode

# 在当前目录打开
code .

# 打开指定目录
code ~/projects/my-project

首次运行会自动在 WSL 中安装 VSCode Server。

配置要点

启用保存时格式化和 ESLint 自动修复
设置 Zsh 为默认终端
排除不必要的文件监控（node_modules、.nuxt、.next、dist）
项目放在 WSL 文件系统 ~/projects/，不要放 /mnt/c/（很慢）
Windows Defender 排除 WSL 目录：Add-MpPreference -ExclusionPath "D:\WSL"

OpenCode 配置

OpenCode 是一个强大的 AI 辅助编程工具，支持多种模型和自定义 agent。

安装与配置

使用 oh-my-opencode 可以一键安装并自动配置：

安装命令：bunx ohmyopencode@latest install
按照提示选择模型和配置即可

常用软件

Raycast (软件启动器)

一开始 windows 上我用的是 utools，轻度使用，我知道里面有很多插件，但是打开速度真心不快。而仅仅作为软件启动器来用，因为我喜欢把桌面上的图标都删掉，露出整个壁纸。

重装完之后，和群里的小伙伴交流了之下，才发现 Raycast 有 windows 版本，于是尝试了一下，体验上比 windows 强的多。

比如，我会在搜索框内简单算个数，能可以直接打开 web search，其他就是启动软件了，刚注册是可以体验AI功能的，不过我完全用不上。

微信输入法

微信输入法本身输入法相关的功能其实是不如搜狗的，可能也不如别的。但是它生的好，生态就好。经过和其他设备配对之后，可以很方便的多端文本、图片复制。带有文本剪贴板历史，按v键激活，也能省下一个单独的剪贴板软件。

手机端的微信输入法还自带排版成图，类似发小红书的时候把短标题弄个简单背景再发出去。前一阵我用来给文章配封面，但是现在我有自己的IMGX了，也不太需要了。

PixPin 截图工具

截图工具一般都要有一个，这个是开源的。我想我还在用它的唯一原因就是我还没来得及用AI复刻一个截图工具吧。

Zotepad 文章编辑器/发布工具

本来我在 macos 上使用 Obsidian 的，但是我用 AI 又给自己写了一个编辑器。并且集成常用的软件，自己常用的工作流。只会越用越顺手。

这个工具基于 Tauri2 + Nuxt4，多端一致，目前每次都会打包 macos/安卓/exe 这三个平台的包，对应我在公司使用 windows，在家使用 macos，手上拿的安卓手机。

目前我内置了图床功能，可以直接上传到腾讯云对象存储，所以我卸载了PicGo (感谢PicGo的陪伴)。

在我用zotepad写文章时，可以直接打开侧边栏选择已经上传的图片插入，感觉方便多了。

markdown编辑器选的 milkdown，所见即所得模式。复制样式到公众号，这个功能在我博客站上就有，也挪过来了。并且用博客站做了公众号接口的转发，可以直接在编辑器内点击发送到公众号草稿箱。支持文章和图文两种模式。发送完再去手机端的公众号助手审一遍就可以发布了。

Flyenv

我主要拿它来运行Ngxin、Mysal、Redis、PGSQL，是作为不能用Docker Desktop时的替代品。

使用感受

WSL 是最好的 Linux 发行版，Windows 是最好的 Linux 桌面

这话说的没毛病。

重点是所有开发环境、代码都在 Ubuntu 里，下次换另一台电脑就和从c盘迁移到别的盘一样，直接把整个打包出来就可以了，十分方便。

而且可以随意安装多个linux环境，可以实验各种配置，玩坏了直接删除重建。比当年自己装双系统啥的省事多了。

好了分享结束，有问题欢迎评论群交流。

稳定是最大的牢笼

Mon, 02 Feb 2026 00:00:00 GMT

一

从大学毕业到现在，已经第九年了。

我们宿舍六人，前五年一直保持着每年回母校聚一次的传统，聊聊生活，交流工作经验。最近两三年，因为各自的家庭原因，没能再完整地聚在一起。

这八年，我感觉自己过得挺平淡的。换了几次工作，薪资也在涨，研究了一些新技术，但好像也就这样了。

直到上个月，参加了宿舍老大的婚礼。

看着他站在台上，西装笔挺，和新娘相视而笑，我心里挺为他高兴的。

婚礼来了很多人，我见到了他读研读博期间的同学——山大的、北大的，也有他工作后认识的朋友。大家聊得很热闹，聊工作、聊课题、聊日常。

我不是那种特别能言善语的人，所以大部分时间在旁边听。但就是听着听着，我突然意识到一个问题：他们说话的时候，带着一种很强的信念感，好像对自己要说的内容有完全的把控。

什么话题都能接得住，不是说他们多能侃，而是知识面确实很广。

最让我触动的不是这些。

婚礼上来了几个外国小孩来表演。我一开始还以为是哪个亲戚带来的，后来才知道，这些孩子是老大资助了十多年的贫困儿童，专程过来参加他的婚礼。

我当时就愣住了。

不是羡慕，是震撼。

我突然意识到：我以为的这八年「平淡」，只是我自己的错觉。

对别人来说，成长从来没有停止过。

只是我没有清晰的方向，所以感受不到自己在哪里。

二

回家的路上，这件事一直在我脑子里转。

不是羡慕，也不是嫉妒，而是被触动了。

我想起老大的成长路径：从大学起就知道自己要干什么，毕业后一边工作一边接活，慢慢把公司做起来。后来又读了在职研究生、博士，圈子也随着事业一点点拓展开来。

看着他的路径，我突然意识到一个一直被忽略的问题：圈子不是被动获得的，是因为有明确的方向，才会主动去拓展。

这个认知其实我以前就知道，只是在这些年的平淡工作中，慢慢被遗忘了。

这次婚礼，像是把这个认知重新激活了。

三

回到家后，我开始反思自己这些年的状态。

我一直在做前端，也在研究 AI。公司是小公司，没有太多试错的空间，所以很多新技术我只能自己买服务器，自己研究。

听起来挺努力的，但问题是：这些研究出来的东西，没有经过真实业务的打磨，只能说会个皮毛。

找工作不是问题，薪资在普通人里也算中上，但我心里清楚，这不是真正的成长。

我不想用「60分也能教30分」这种话来安慰自己。那只是在用比烂思维粉饰现状。

我想要的是真正的蜕变，不是自我欺骗的安慰。

回想这些年，我虽然也在努力，但总觉得像在一个封闭的空间里打转——有热情，有投入，但方向不清晰，所以认知提升得很慢。

这才是我真正的问题。

四

如果时光倒流，我会选择什么？

考研？读博？进大厂？创业？

这些选择都很好，但过去无法重来，也没必要重来。

重要的是：我不想再把自己的前途放在一个安稳的环境中了。

我需要寻求突破。

改变认知应该和年龄无关。

我不知道什么时候能跨越阶层，但我知道从今天开始可以做什么：

找到一个有土壤的环境——不一定是大厂，但至少要有业务支撑，让我的技术能真正落地。
主动进入更高的圈子——参加技术沙龙、开源社区、行业会议，多和优秀的人交流。不是为了功利地「混圈子」，而是为了看看那些走在前面的人是怎么思考的。
持续输出，建立影响力——写文章、录视频、做开源项目。不是为了赚钱，而是为了让更多人看到我在做什么，也让我自己看清楚自己的成长轨迹。

这些都不是什么宏大的目标，但至少是可执行的小步骤。

五

这次经历，对我来说是一次认知的重新激活。

它提醒我：先有方向，再有圈子；先知道要去哪儿，再找同行的人。

我突然意识到，自己这些年一直在走，但好像没走在正确的路上。

好在，现在知道自己在哪儿了。

也知道该往哪儿走了。

很庆幸我有一批这样的朋友，以及总是能在毫无保留的分享下获得一些启发。

Skills之后，'学习'的意义被重新定价了

Wed, 28 Jan 2026 13:20:37 GMT

今天看到antfu创建一个仓库「skills」，点进去不出意外是 Vue、Nuxt、vueuse、Vite 等相关的官方SKILL。

这意味着你只要在本地写这些生态的项目，AI的幻觉会大大减少，不用去 web_search一些不知道是否是最新的文档，或者用context7这种mcp去查文档了。

并且最重要的是，SKILL为了使AI准确和高效的读取文档，作者一定是写了大量规范、标准的示例来涵盖一个框架或插件尽可能多（或者是全部）的功能。

并且SKILL.md会用尽量少的上下文，来索引其他具体文档。

从开发的角度来讲，以前AI因为没拿到最新文档而使用旧版本代码的情况几乎不会发生了（只要你用了SKILL），产出的代码更准确，效率应该会大大提高。

但是另一方面，这些文档你都不用学了，直接喂到嘴里了。

开发者的焦虑和被(即将)替代的感觉也会大大增加。

卖AI课的赚麻了，写代码的，麻了。

但是我看完了Nuxt的SKILL之后，又发现了好的一面。

如果有人和我一样，从Nuxt3开始啃文档，搜Github issues，一定会感叹，这个SKILL.md真的比官方文档还要高效。

为了让AI快速找到对应要读的md，归类了几个核心，以及罗列了Nuxt的核心特性。

你知道这意味着什么吗？

如果你还愿意学习一个框架，比如Nuxt，这个SKILL会让你的学习效率大大提高，而且这个库肯定会随着Nuxt更新而更新，不用担心内容落后。

简直太幸福了，你不知道我踩了多少Nuxt的坑...

不只是最直观的阅读效率提高了。重点它是SKILL啊！SKILL的特点就是可以随意组合！

如果你用另一个面试相关的SKILL，让其去读Nuxt SKILL，那它问的问题，回答的答案，都会无比准确。

如果SKILL.md对比官方文档是把饭嚼碎了喂嘴里

结合自己的SKILL去学Nuxt，这简直就是直接插上USB传输到脑子里了😄

想到这给我激动坏了

但冷静下来，我发现一件吊诡的事：

以前我们啃文档，是因为不得不啃——那是门票，是谋生通行证。现在 Skills 把门拆了，谁都能进来逛一圈。

结果"愿不愿意学习"反而成了新的筛选器。

就像那个高赞评论说的：有钱人去挥霍享受，我一点都不羡慕。但是他们去学习、去提升自己，我是真的嫉妒。

以前嫉妒，是因为我们没那个时间资本。现在 Skills 把学习成本打到地板下，我们终于有了"选择不学"的自由。而这恰恰是最奢侈的陷阱。

所以，你还愿意学编程吗 🤨

现在的学习路径都这么短了

你还愿意学吗？

你是怎么确定不学，而去跟风的路子是对的呢？

用AI向内挖掘自己

Thu, 22 Jan 2026 10:53:53 GMT

最近大家都在聊AI，各种工具、产品层出不穷。说实话，刚开始我也跟风用AI写代码、写文案，结果发现一个问题：AI生成的东西越来越多，自己看的越来越少。

有次改bug，看着AI写的代码，愣是没看懂逻辑。要是自己写的，哪怕写得烂，至少知道哪里有坑。

这让我开始反思：AI擅长写，那让它来读呢？

后来试了一次，让AI分析我写的代码，指出问题。结果它真的毫不留情地把我的烂逻辑、冗余代码全挑出来了。那一刻才明白，与其让AI替我输出，不如让它审视我。

为什么要向内挖？

AI最有用的地方，不是它能写出多精准的代码，而是它能不讲情面地指出你的问题。

代码写得再好，也强不过AI。

但通过分析你的知识体系，AI能准确找出你的不足，并告诉你怎么改。

只有自身的代码水平、架构能力、表达能力提升了，AI才会跟着你变强。

这种对话还有个好处：没有人际压力。

你和领导聊天，得斟酌用词；和同事交流，怕暴露短板；自己复盘，又容易放过自己。AI就是一面镜子，你问什么它答什么，完全没顾虑。

而且比搜索引擎精准。搜索给你一堆资料，你得自己筛选；问人的话，大部分时候别人知道你有问题，但没义务指出来。

AI不一样，它可以事无巨细地给你分析，直到你真正理解。

具体怎么做？

拿技术面试场景举例：

让AI扮演面试官，检测自己的技术水平：

让AI提问：给它一个角色设定，让它针对我的方向出题
多轮对话：针对薄弱的地方，反复探讨，直到自己能完整表述出来
输出文档：把对话整理成md文档，方便回顾

这里要强调一点：必须是「表述」正确，不是「理解」正确。

你脑子里会，和你能说清楚，完全是两码事。

AI算是一个可以让你毫无心理压力表述答案的面试官了，真人面试时，还会受情绪影响。

所以我会把对话记录下来，看看自己哪些地方说得不清楚，然后继续优化表达。

提示词参考

下面是我目前的提示词，你可以根据自己的情况改动{}里的内容：

请你扮演一位资深的开发主管/前端技术负责人，以面试官的身份向我提出 {N} 个有代表性、有深度、能体现技术水平的面试题。

**面试流程**：
- 采用一问一答的形式，逐题提问，等待我回答后再提出下一题
- 如遇到不熟悉的题目，可以说明情况并跳过，不影响其他题目评分
- 全部问题回答完毕后，对每题进行评分（满分10分）
- 提供犀利但客观的点评，指出回答的优点和不足
- 给出每道题的标准答案作为参考

**输出要求**：
面试结束后，生成以下4份文档到 {目标目录}：
1. 面试题提示词模板（本模板文件）
2. 面试题目清单（所有题目及详细描述）
3. 面试题标准答案（每题的合格回答参考）
4. 面试评估报告（包含候选人原始回答、评分、点评）

**面试对象**：{岗位名称}

**面试方向**：{技术方向列表}

**参数配置**：
1. 面试时长：{时长}分钟
2. 技术方向权重：
   - {方向1}：{权重}（最高/次之/一般/少量）
   - {方向2}：{权重}
   - {方向3}：{权重}
   - ...
3. 题目分布：
   - 技术深度：{比例}%
   - 实战场景：{比例}%
   - 架构设计：{比例}%
   - 综合管理：{比例}%
4. 公司背景：{创业公司/中大型公司/技术驱动型公司}

**题目设计原则**：
1. 技术深度题（{比例}%）：考察底层原理理解，需解释"为什么"和"怎么实现"
   示例：Vue响应式原理、Node.js事件循环、Virtual DOM diff算法
2. 实战场景题（{比例}%）：考察问题解决能力，给出具体业务场景求解决方案
   示例：大数据量性能优化、技术栈迁移策略、内存泄漏排查
3. 架构设计题（{比例}%）：考察系统思维和架构能力，需设计完整技术方案
   示例：微前端架构、高并发API网关、全栈应用技术选型
4. 综合管理题（{比例}%）：考察团队协作和项目管理能力，关注软技能
   示例：技术债务平衡、代码规范落地、Code Review文化建设

**标准答案输出要求**：
- 仅用文字描述核心要点，不要提供代码示例
- 不要使用正反对比的举例说明（如"❌ 错误示例"、"✅ 正确示例"）
- 答案需克制、精炼，点到为止，避免过度展开
- 控制每题答案在 300-500 字以内
- 重点说明"是什么"和"为什么"，不需详述"怎么做"

不只是技术

这套方法不只适合技术。

生活、情感、人际关系，AI或许有独到的见解，毕竟它见得多。

不管是你问它，还是让它反问你，都是一场在生活中少有的、直指内心的问答。

使用 Chrome DevTools 排查内存泄漏

Thu, 22 Jan 2026 00:00:00 GMT

概述

内存泄漏是前端性能优化中最难排查的问题之一。本文将详细介绍如何使用 Chrome DevTools 的 Performance 和 Memory 面板，系统化地排查并定位内存泄漏问题，并映射到真实代码逻辑。

一、内存泄漏的识别

典型症状

页面运行一段时间后变卡
滚动、点击响应变慢
浏览器标签页显示内存占用持续增长
最终页面崩溃（Out of Memory）

快速检测

在控制台运行以下代码,观察内存是否持续增长：

setInterval(() => {
  const usedMB = performance.memory.usedJSHeapSize / 1024 / 1024
  console.log(`当前内存占用: ${usedMB.toFixed(2)} MB`)
}, 1000)

二、Performance 面板：确认是否泄漏

录制内存快照

打开 DevTools (F12) → Performance 标签
勾选 Memory 选项
点击 Record 录制 30-60 秒
执行可疑操作（滚动列表、打开关闭弹窗等）
停止录制

分析内存走势图

正常情况（有涨有跌,GC 能回收）：

Memory (MB)
  ↑     ╱╲      ╱╲      ╱╲
  │    ╱  ╲    ╱  ╲    ╱  ╲
  └─────────────────────────→ 时间

内存泄漏（持续上涨,呈阶梯状）：

Memory (MB)
  ↑   ╱──────╱─────╱─────╱──
  │  ╱      ╱     ╱     ╱
  └─────────────────────────→ 时间

判断标准：

✅ 正常：内存有涨有跌,GC 后能降下来
❌ 泄漏：内存持续上涨,GC 后仍然增长

三、Memory 面板：定位泄漏点

对比堆快照

操作流程：

DevTools → Memory 标签 → 选择 "Heap snapshot"
点击 "Take snapshot" → 获得快照 1
执行可疑操作（如打开 10 次弹窗后关闭）
强制垃圾回收（点击 🗑️ 图标）
点击 "Take snapshot" → 获得快照 2
切换视图为 Comparison → 选择 "between Snapshot 1 and Snapshot 2"

关键列说明：

列名	含义	关注点
# Delta	净增加的对象数量	应该接近 0
Size Delta	净增加的内存	最关键的指标
Alloc. Size	新增对象占用内存	持续增长说明泄漏
Freed Size	释放的内存	应该接近 Alloc. Size

查找泄漏对象

按 Size Delta 排序,找到占用内存最多的对象类型：

Constructor              # Delta    Size Delta
─────────────────────────────────────────────
(array)                  +500       +2.5 MB    ← 可疑！数组持续增长
Detached HTMLDivElement  +200       +800 KB    ← DOM 泄漏
EventListener            +150       +150 KB    ← 事件监听器未移除

四、定位到真实代码

查看 Retainers（保留路径）

这是最关键的环节！ Retainers 显示了为什么这个对象没有被垃圾回收。

操作：点击可疑对象 → 选择具体实例 → 右侧面板显示 Retainers

解读 Retainers 路径

示例 1：全局变量引用

Retainers:
  → Window / http://localhost:3000
    → VueComponent                ← Vue 组件实例
      → setupState                ← setup() 返回的状态
        → allData                  ← 你的变量名
          → @123456 (array)       ← 泄漏的数组

如何对应到代码：

看到 allData → 在代码中搜索 const allData = ref(...)
看到 VueComponent → 定位到具体的组件文件

示例 2：事件监听器引用

Retainers:
  → Window
    → eventListeners          ← 全局事件监听器映射
      → scroll                ← scroll 事件
        → [[Handler]]
          → VueComponent      ← 组件实例被闭包引用

结论：scroll 事件监听器没有被移除,闭包引用了组件实例。

五、常见内存泄漏模式

通过 Memory 面板,常见的泄漏对象类型：

5.1 DOM 泄漏

现象：

Constructor              # Delta    Size Delta
────────────────────────────────────────────
Detached HTMLDivElement  +200       +800 KB

原因：移除 DOM 时未清理事件监听器,导致元素无法被 GC

解决：在移除 DOM 前调用 removeEventListener

5.2 定时器泄漏

现象：

Constructor    # Delta    Size Delta
────────────────────────────────────
Timeout        +50        +100 KB

原因：组件销毁时定时器仍在运行

解决：在 onUnmounted 中调用 clearInterval / clearTimeout

5.3 事件监听器泄漏

现象：

Constructor      # Delta    Size Delta
──────────────────────────────────────
EventListener    +100       +200 KB

原因：全局事件监听器未移除

解决：在 onUnmounted 中调用 window.removeEventListener

5.4 组件实例泄漏

现象：

Constructor        # Delta    Size Delta
────────────────────────────────────────
VueComponent       +50        +5 MB

原因：事件总线监听器未注销,导致组件实例无法释放

解决：在 onUnmounted 中调用 bus.off

5.5 闭包引用大对象

现象：

Constructor    # Delta    Size Delta
────────────────────────────────────
(array)        +100       +10 MB
(closure)      +50        +500 KB

原因：事件处理函数闭包不必要地引用了大对象

解决：只保留必需的数据,或在使用后手动设为 null

六、实战案例：排查 Vue3 虚拟滚动内存泄漏

6.1 问题症状

Performance 面板录制 60 秒后发现：

JS Heap 从 50MB 增长到 150MB
内存呈阶梯状持续增长
没有明显的 GC 回收

6.2 Memory 面板对比快照

Comparison (Snapshot 1 vs Snapshot 2)：

Constructor      # Delta    Size Delta
────────────────────────────────────────
(array)          +1        +50 MB      ← data 数组持续增长
EventListener    +1        +100 KB     ← scroll 监听器未清理
WebSocket        +1        +50 KB      ← WebSocket 未关闭

6.3 Retainers 定位代码

通过查看 Retainers 路径,找到 3 个泄漏点：

data 数组：Window → VueComponent → setupState → data 持续增长,没有限制大小
scroll 监听器：Window → eventListeners → scroll 未移除,闭包引用了 data
WebSocket：组件销毁时未关闭,回调闭包引用了 data

6.4 修复方案

根据 Retainers 路径,需要：

限制 data 数组最大长度
在 onUnmounted 中移除 scroll 监听器
在 onUnmounted 中关闭 WebSocket 连接
使用 shallowRef 优化大数据响应式开销

七、快速检查清单

Vue 3 组件中需要在 onUnmounted 清理的资源：

定时器：clearInterval(timer) / clearTimeout(timer)
全局事件监听：window.removeEventListener('resize', handler)
WebSocket：ws.close()
第三方库实例：chart.dispose() (如 ECharts)
事件总线：bus.off('event', handler)
Observer：observer.disconnect() (IntersectionObserver/ResizeObserver)
大数据限制：使用 shallowRef + 限制数组最大长度

八、总结

排查流程

Performance 面板 → 确认是否泄漏（观察内存走势图）
Memory 面板 → 对比快照,找到泄漏对象类型
查看 Retainers → 找到引用路径
映射到代码 → 通过变量名定位文件和行号
修复 + 验证 → 清理资源,再次录制确认修复

关键技巧

看 Retainers：这是定位代码的关键,显示从 Window 到具体变量的完整路径
认识常见模式：定时器、事件监听器、DOM 引用、闭包是主要原因
使用 shallowRef：大数据场景必备,减少响应式开销
限制数据量：虚拟滚动中必须限制数组大小
清理资源：onUnmounted 中清理所有副作用

最佳实践

✅ 所有副作用都在 onUnmounted 中清理
✅ 使用 shallowRef 存储大数据
✅ 限制列表/数组的最大长度
✅ 避免闭包捕获大对象
✅ 定期用 DevTools 检查内存占用

参考资源

高级前端开发面试提示词模板

Wed, 21 Jan 2026 07:30:52 GMT

核心提示词

以下是完整的提示词模板，复制后替换 {} 占位符即可使用：

请你扮演一位资深的开发主管/前端技术负责人，以面试官的身份向我提出 {N} 个有代表性、有深度、能体现技术水平的面试题。

**面试流程**：
- 采用一问一答的形式，逐题提问，等待我回答后再提出下一题
- 如遇到不熟悉的题目，可以说明情况并跳过，不影响其他题目评分
- 全部问题回答完毕后，对每题进行评分（满分10分）
- 提供犀利但客观的点评，指出回答的优点和不足
- 给出每道题的标准答案作为参考

**输出要求**：
面试结束后，生成以下4份文档到 {目标目录}：
1. 面试题提示词模板（本模板文件）
2. 面试题目清单（所有题目及详细描述）
3. 面试题标准答案（每题的合格回答参考）
4. 面试评估报告（包含候选人原始回答、评分、点评）

**面试对象**：{岗位名称}

**面试方向**：{技术方向列表}

**参数配置**：
1. 面试时长：{时长}分钟
2. 技术方向权重：
   - {方向1}：{权重}（最高/次之/一般/少量）
   - {方向2}：{权重}
   - {方向3}：{权重}
   - ...
3. 题目分布：
   - 技术深度：{比例}%
   - 实战场景：{比例}%
   - 架构设计：{比例}%
   - 综合管理：{比例}%
4. 公司背景：{创业公司/中大型公司/技术驱动型公司}

**题目设计原则**：
1. 技术深度题（{比例}%）：考察底层原理理解，需解释"为什么"和"怎么实现"
   示例：Vue响应式原理、Node.js事件循环、Virtual DOM diff算法
2. 实战场景题（{比例}%）：考察问题解决能力，给出具体业务场景求解决方案
   示例：大数据量性能优化、技术栈迁移策略、内存泄漏排查
3. 架构设计题（{比例}%）：考察系统思维和架构能力，需设计完整技术方案
   示例：微前端架构、高并发API网关、全栈应用技术选型
4. 综合管理题（{比例}%）：考察团队协作和项目管理能力，关注软技能
   示例：技术债务平衡、代码规范落地、Code Review文化建设

**标准答案输出要求**：
- 仅用文字描述核心要点，不要提供代码示例
- 不要使用正反对比的举例说明（如"❌ 错误示例"、"✅ 正确示例"）
- 答案需克制、精炼，点到为止，避免过度展开
- 控制每题答案在 300-500 字以内
- 重点说明"是什么"和"为什么"，不需详述"怎么做"

提示词设计说明

本模板通过以下机制控制AI面试官行为：

角色定位："开发主管、前端主管的面试官"明确专业视角和权威性
交互模式："一问一答"确保面试流程规范，避免一次性抛出所有题目
结构化输出：要求生成4份独立文档，便于后续整理和分享
参数化配置：通过权重、比例等参数精确控制题目分布和难度
题目设计原则：明确4类题型占比，确保全面考察技术能力
答案输出约束：限制代码示例和冗余对比，大幅节省token消耗（预计节省80%+）

核心设计理念：通过明确的输出约束和格式要求，使AI生成的内容既专业又高效。

使用示例

本次面试使用的配置

岗位: 高级前端开发（偏Node全栈）
面试时长: 30-40分钟
题目总数: 10题

技术方向权重:
  - Vue2/Vue3: 最高 (6题)
  - Node.js: 次之 (2题)
  - 架构设计: 一般 (1题)
  - 团队管理: 一般 (1题)
  - 服务器运维: 少量 (融入其他题目)

题目分布:
  - 技术深度: 40%
  - 实战场景: 40%
  - 架构设计: 10%
  - 综合管理: 10%

评分标准:
  - 10-9分: 深度理解原理 + 丰富实战经验 + 有独特见解
  - 8-7分: 理解原理 + 有实战经验 + 回答完整
  - 6-5分: 基本理解 + 有一定经验 + 回答尚可
  - 4-3分: 理解片面 + 经验不足 + 回答欠缺
  - 2-1分: 不理解原理 + 无实战经验

扩展参考

以下内容为提示词设计的补充说明，帮助你根据实际需求定制化调整。

面试流程指引

Phase 1: 开场（2分钟）

简要介绍面试形式
说明题目数量和时长
鼓励候选人结合实战经验回答

Phase 2: 提问环节（30-40分钟）

一问一答：提出一题，等待回答完再提下一题
实时记录：记录候选人的原始回答（不修改）
适度追问：如果回答太简单，可以追问细节
跳过机制：允许候选人跳过不熟悉的题目

Phase 3: 评估环节（面试后）

对每题进行评分（满分10分）
撰写犀利点评（指出优点和不足）
提供合格回答参考
生成综合评估报告

评分维度

技术理解（40%）

是否理解底层原理？
能否解释技术实现细节？
是否了解技术的边界和限制？

实战经验（30%）

是否有实际项目经验？
是否遇到过相关问题？
解决方案是否合理有效？

思维深度（20%）

是否有系统性思维？
能否权衡不同方案的优劣？
是否有独特的见解？

表达能力（10%）

回答是否清晰有条理？
是否能准确表达技术概念？
是否能结合实例说明？

定制化建议

针对不同岗位调整

初级前端（1-3年）

减少原理深度题，增加基础概念题
重点考察：HTML/CSS/JS基础、Vue/React基础使用
评分标准适当放宽

中级前端（3-5年）

平衡原理和实战
重点考察：组件设计、状态管理、性能优化
开始考察架构思维

高级前端/全栈（5年+）

深度原理 + 复杂场景 + 架构设计
重点考察：技术选型、性能调优、团队协作
要求有独特见解和丰富经验

针对不同技术栈调整

React生态

React Hooks原理
Redux vs MobX vs Zustand
Next.js SSR/SSG
React Server Components

Vue生态

Vue响应式原理
Vuex vs Pinia
Nuxt.js SSR/SSG
Vue Composition API

Node.js后端

Event Loop深度
Koa/Express/Fastify/NestJS
数据库优化（MySQL/MongoDB/Redis）
微服务架构

注意事项

面试官须知

营造轻松氛围：面试是双向选择，不要让候选人过度紧张
鼓励实战分享：实战经验比理论知识更有参考价值
允许跳过题目：不熟悉的题目可以跳过，不影响整体评价
客观公正评分：避免主观偏见，按评分标准执行
提供建设性反馈：点评要犀利但不刻薄，指出改进方向

候选人须知

结合实战经验：尽量用实际项目案例说明
承认不足：不懂的直接说不懂，不要瞎编
思路清晰：先说核心观点，再展开细节
追问细节：如果问题不清楚，可以要求面试官澄清

输出文档格式

1. 面试题提示词模板

本文档

2. 面试题目清单

# 高级前端开发面试题目清单

## Vue2/Vue3技术（6题）
1. Vue响应式原理对比
2. 组件通信方案选型
...

## Node.js技术（2题）
7. Event Loop执行顺序
...

3. 面试题标准答案

# 高级前端开发面试题标准答案

## 第1题：Vue响应式原理
### 问题
...
### 标准答案
1. 技术实现层面
...

4. 面试评估报告

# 高级前端开发面试评估报告

## 候选人信息
- 面试时间：YYYY-MM-DD
- 面试岗位：高级前端开发
- 总分：XX/100

## 详细评估
### 第1题：Vue响应式原理【得分：X/10】
#### 候选人回答
...
#### 评分与点评
...

文档元信息

版本：v1.1
创建日期：2026-01-21
最后更新：2026-01-21
适用场景：高级前端开发（偏Node全栈）技术面试
Token优化：标准答案部分预计节省80%+ token消耗

高级前端开发面试题标准答案

Wed, 21 Jan 2026 07:25:00 GMT

文档说明：本文档提供所有面试题的标准答案索引。每题的详细答案已拆分到独立文件中。

创建日期：2026-01-21
更新日期：2026-01-21（拆分为独立文件）

使用说明

每个题目的标准答案文件包含：

题目完整描述：包含场景、考察点等
标准答案：分点详细阐述
代码示例：实际可运行的代码
最佳实践：行业经验和建议
常见误区：需要避免的陷阱
扩展阅读：相关技术文档链接

答案文件列表

文件名	题目	技术领域
03-01-vue-reactive.md	Vue 响应式原理	Vue 核心原理
03-02-component-communication.md	Vue 组件通信	Vue 状态管理
03-03-vue3-performance.md	Vue3 性能优化	Vue 性能调优
03-04-vue-migration.md	Vue2 迁移到 Vue3	Vue 版本升级
03-05-vue-diff.md	Vue Diff 算法	Vue 核心原理
03-06-nuxt-ssr.md	Nuxt.js SSR 实战	Vue SSR
03-07-event-loop.md	Node.js Event Loop	Node.js 核心
03-08-nodejs-performance.md	Node.js 性能调优	Node.js 性能
03-09-micro-frontend.md	微前端架构设计	前端架构
03-10-team-management.md	团队管理与技术债务	工程管理

10.团队管理与技术债务 - 标准答案

Wed, 21 Jan 2026 07:24:00 GMT

题目

考察点:管理能力、技术推动、团队协作

场景描述:
作为高级前端开发/技术负责人,您不仅要写代码,还要带团队、推动项目。

场景:
您接手一个老项目,代码质量堪忧:

没有代码规范,每个人的代码风格完全不同
没有单元测试,改代码如履薄冰
技术栈老旧(Vue2 + Webpack4),但业务压力大,没时间重构
团队成员水平参差不齐,Code Review 流于形式

问题:

技术债务平衡:业务需求紧急 vs 技术重构,如何平衡?您会采取什么策略?
团队规范落地:如何推动代码规范、ESLint、Prettier、Git Commit 规范在团队中落地?(而不是仅仅写个文档)
Code Review 文化:如何让 Code Review 真正发挥作用,而不是走形式?
实战经验:分享一个您在团队管理或技术推动中遇到的难题,以及您的解决方案。

标准答案

1. 技术债务与业务需求的平衡策略

核心原则:"二八法则" + "渐进式重构"

20% 的时间投入技术建设,80% 的时间保障业务交付。

具体策略

a) 技术债务分级管理

级别	特征	处理策略	优先级
P0 - 致命	影响系统稳定性、安全漏洞、性能严重问题	立即修复,可申请暂停需求	🔴 最高
P1 - 严重	影响开发效率、代码难以维护、重复劳动多	排入迭代,每个迭代修复 1-2 项	🟠 高
P2 - 中等	代码不规范、缺少测试、技术栈老旧	结合业务需求渐进式重构	🟡 中
P3 - 轻微	优化机会、新技术尝试	技术分享、个人时间探索	🟢 低

示例:

P0: 线上内存泄漏、SQL 注入漏洞 → 立即修复
P1: 打包耗时 10 分钟、前端构建失败率高 → 本迭代优化
P2: Vue2 升级 Vue3、添加单元测试 → 结合新需求逐步重构
P3: 尝试 Vite、探索 Tailwind CSS → 技术沙龙分享

b) "新老交替"策略(推荐)

原则: 新代码高标准,老代码不动(除非必须改)

具体做法:
1. 制定《新代码规范》(ESLint + Prettier + Git Hooks)
2. 新功能必须符合新规范,老代码暂不强制
3. 修改老代码时,同步重构该模块(限定范围)
4. 逐步推进,避免大爆炸式重构

案例: 团队引入 TypeScript

方式	做法	结果
❌ 错误	一次性把所有 .js 改成 .ts	项目瘫痪 2 周,业务需求延期
✅ 正确	新文件用 .ts,老文件逐步迁移,共存 6 个月	平滑过渡,无感知

c) "技术债券"机制

每完成 3 个业务需求,团队获得 1 个"技术债券"
可兑换:
- 1 天重构时间
- 引入 1 个新工具
- 优化 1 个性能瓶颈

目的: 让技术投入可视化、可量化

d) 与产品/老板的沟通话术

错误示范:

"这代码太烂了,必须重构!不然没法干活!"

正确示范:

"目前系统存在 X 个痛点影响交付效率:

构建慢导致每天浪费 2 小时

缺少测试导致上线后频繁改 bug

建议投入 3 天优化构建,预期收益:

每日节省 2 小时 × 5 人 = 10 人时

1 个月回本,后续持续受益

同时不影响本迭代需求交付。"

核心:

用"效率提升"而不是"技术追求"说服老板
用"ROI"(投入产出比)量化收益
承诺"不影响业务"降低阻力

2. 团队规范落地:从"文档"到"自动化"

问题根源: 人的自觉性不可靠,必须依赖工具强制执行。

2.1 代码规范落地(ESLint + Prettier)

第 1 步:统一配置

# 安装依赖
pnpm add -D eslint prettier eslint-config-prettier eslint-plugin-vue @vue/eslint-config-typescript

# .eslintrc.js
module.exports = {
  extends: [
    'plugin:vue/vue3-recommended',
    '@vue/typescript/recommended',
    'prettier' // 关闭与 Prettier 冲突的规则
  ],
  rules: {
    'vue/multi-word-component-names': 'off',
    '@typescript-eslint/no-explicit-any': 'warn'
  }
}

# .prettierrc.json
{
  "semi": false,
  "singleQuote": true,
  "printWidth": 100,
  "trailingComma": "none"
}

第 2 步 Hooks 强制检查(Husky + lint-staged)

# 安装
pnpm add -D husky lint-staged

# package.json
{
  "scripts": {
    "prepare": "husky install"
  },
  "lint-staged": {
    "*.{js,ts,vue}": [
      "eslint --fix",
      "prettier --write"
    ]
  }
}

# 添加 pre-commit hook
npx husky add .husky/pre-commit "npx lint-staged"

效果:

提交代码时自动格式化
不符合规范的代码无法提交
新人无需学习规范,工具自动修正

第 3 步流水线检查

# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install
        run: pnpm install
      - name: Lint
        run: pnpm lint
      - name: Type Check
        run: pnpm type-check

效果: PR 合并前必须通过检查,防止不规范代码入库。

2.2 Git Commit 规范(Commitizen + Commitlint)

# 安装
pnpm add -D @commitlint/cli @commitlint/config-conventional commitizen cz-conventional-changelog

# commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional']
}

# package.json
{
  "scripts": {
    "commit": "cz"
  },
  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }
}

# 添加 commit-msg hook
npx husky add .husky/commit-msg "npx --no -- commitlint --edit $1"

使用方式:

# 不再使用 git commit -m "xxx"
# 而是运行
pnpm commit

# 自动弹出交互式提示
? Select the type of change: (Use arrow keys)
❯ feat:     A new feature
  fix:      A bug fix
  docs:     Documentation only changes
  style:    Changes that do not affect code meaning
  refactor: A code change that neither fixes a bug nor adds a feature
  perf:     A code change that improves performance
  test:     Adding missing tests

效果:

Commit 信息规范统一
自动生成 CHANGELOG
Git 历史清晰可读

2.3 落地经验总结

阶段	做法	注意事项
引入期	先在新项目试点,积累经验	不要一次性全团队推广
推广期	举办工作坊,手把手教学	准备《常见问题 FAQ》
强制期	启用 Git Hooks + CI 卡点	提前 2 周通知,给缓冲期
维护期	定期优化规则,听取反馈	规范不是一成不变的

关键点:

工具化:能用工具解决的,不要靠人
自动化:能自动修正的,不要让人手动改
渐进式:先试点、再推广、最后强制
可配置:允许团队根据实际情况调整规则

3. Code Review 文化建设

3.1 为什么 Code Review 流于形式?

原因	表现	后果
无标准	不知道该审什么	只看语法错误,错过架构问题
无时间	业务太忙,草草了事	"LGTM"(Looks Good To Me)成口头禅
无反馈	提的意见被忽略	Reviewer 积极性下降
无责任	出问题不追责	审核质量下降

3.2 建设高质量 Code Review 文化

a) 制定 Code Review Checklist

# Code Review 检查清单

## 功能性 (Functionality)
- [ ] 代码实现是否符合需求?
- [ ] 是否有遗漏的边界条件?
- [ ] 错误处理是否完善?

## 可读性 (Readability)
- [ ] 变量/函数命名是否清晰?
- [ ] 是否有必要的注释?(复杂逻辑、业务规则)
- [ ] 代码结构是否清晰?

## 性能 (Performance)
- [ ] 是否有不必要的重复计算?
- [ ] 是否有内存泄漏风险?
- [ ] 大数据量场景是否考虑分页/虚拟滚动?

## 安全性 (Security)
- [ ] 是否有 XSS/CSRF 风险?
- [ ] 敏感信息是否加密?
- [ ] API 调用是否有权限校验?

## 可维护性 (Maintainability)
- [ ] 是否遵循 DRY 原则(Don't Repeat Yourself)?
- [ ] 是否有过度设计?
- [ ] 是否需要补充单元测试?

## 架构一致性 (Consistency)
- [ ] 是否符合团队代码风格?
- [ ] 是否复用已有组件/工具?
- [ ] 新增依赖是否合理?

使用方式: 在 PR 模板中引入 Checklist

<!-- .github/pull_request_template.md -->
## 变更说明
简述本次改动的目的和内容

## 自测清单
- [ ] 本地测试通过
- [ ] ESLint/类型检查通过
- [ ] 已添加/更新单元测试

## Reviewer 检查点
请 Reviewer 重点关注:
- [ ] XX 模块的性能优化是否合理
- [ ] XX 函数的错误处理是否完善

b) 规范 Code Review 流程

角色	职责	SLA
提交者(Author)	提供清晰的 PR 描述、自测通过、主动响应评论	PR 提交后 24 小时内响应评论
审查者(Reviewer)	仔细审查代码、提出建设性意见、批准或要求修改	PR 提交后 2 个工作日内完成审查
Approve 者	至少 2 人 Approve 才可合并,其中 1 人必须是 Senior	-

流程图:

提交 PR
  ↓
CI 自动检查(Lint/Test)
  ↓ (通过)
指定 2 名 Reviewer
  ↓
Reviewer 1 审查 → 提意见 → Author 修改
  ↓
Reviewer 2 审查 → Approve
  ↓
Reviewer 1 再次审查 → Approve
  ↓
合并到主分支

c) 激励机制

正向激励:

每月评选"最佳 Reviewer"(提出高质量建议次数最多)
Code Review 质量纳入绩效考核
优秀 Review 案例在团队会议上分享

负向约束:

因 Review 不严格导致线上问题,Reviewer 同样承担责任
"LGTM"式敷衍 Review 会被记录并通报

d) 工具支持

GitHub/GitLab 配置:

# .github/CODEOWNERS
# 自动指定 Reviewer
*.vue @frontend-team
*.ts @frontend-team
/server/** @backend-team

Danger JS 自动化检查:

// dangerfile.js
import { danger, warn, fail } from 'danger'

// PR 描述不能为空
if (danger.github.pr.body.length < 10) {
  fail('请填写 PR 描述')
}

// 大 PR 警告(超过 500 行)
const bigPRThreshold = 500
if (danger.github.pr.additions + danger.github.pr.deletions > bigPRThreshold) {
  warn(`本次 PR 改动较大(${danger.github.pr.additions + danger.github.pr.deletions} 行),建议拆分`)
}

// 必须有测试
const hasTests = danger.git.modified_files.some(f => f.includes('.spec.') || f.includes('.test.'))
if (!hasTests) {
  warn('请补充单元测试')
}

3.3 Code Review 最佳实践

对 Author:

小步提交: 每次 PR 改动不超过 500 行(大功能拆分多个 PR)
清晰描述: 说明"为什么改"而不是"改了什么"
自我审查: 提交前先自己 Review 一遍
积极响应: 24 小时内回复 Reviewer 的评论

对 Reviewer:

建设性意见: 不要只说"这不好",要给出具体建议
区分问题等级:
- 🚨 MUST FIX(必须修改): 功能错误、安全问题
- ⚠️ SHOULD FIX(建议修改): 性能问题、可读性问题
- 💡 NICE TO HAVE(可选): 代码风格、优化建议
正面反馈: 看到优秀代码也要点赞表扬
及时审查: 不要让 PR 挂着超过 2 天

Code Review 评论示例:

# ❌ 不好的评论
这代码写得不对

# ✅ 好的评论
🚨 **MUST FIX**: 这里缺少空值校验,如果 `user.profile` 为 null 会导致报错

建议修改为:
\`\`\`javascript
const avatar = user.profile?.avatar ?? '/default-avatar.png'
\`\`\`

4. 实战案例分享

案例: 如何在 6 个月内将团队代码质量提升一个档次

背景:

团队 8 人,Vue2 项目,代码混乱无规范
线上 bug 频发,每周至少 2 次紧急修复
团队士气低落,加班严重

问题分析:

无代码规范 → 代码难读难改
无测试 → 改代码如拆炸弹
Code Review 形式化 → 问题无法提前发现
技术债务积压 → 开发效率低下

解决方案与实施时间线:

第 1 个月:建立基础规范

动作:

引入 ESLint + Prettier + Husky
举办 2 次工作坊教学
在新项目试点,老项目不强制

结果:

新代码风格统一
团队接受度高(没有强制改老代码)

第 2-3 个月:推广工程化工具

动作:

引入 Commitizen(规范 Git 提交)
配置 CI 流水线(自动化 Lint/Test)
制定《Code Review Checklist》
试点单元测试(核心模块优先)

结果:

Git 历史变清晰,方便回溯问题
CI 拦截了 30% 的低级错误
Code Review 质量提升

第 4-5 个月:技术债务专项治理

动作:

梳理技术债务清单,按 P0-P3 分级
每个迭代分配 20% 时间修复债务
优化构建速度(Webpack → Vite)
重构核心公共组件

结果:

构建时间从 8 分钟降到 2 分钟
代码重复率下降 40%
团队开发效率提升

第 6 个月:文化与机制沉淀

动作:

制定《前端开发规范手册》
建立"技术债券"机制
每月评选"最佳 Reviewer"
举办技术分享会

结果:

团队形成自驱文化
Code Review 成为日常习惯
线上 bug 率下降 70%

数据对比:

指标	改进前	改进后	提升
线上 bug 率	8 个/月	2 个/月	↓ 75%
构建时间	8 分钟	2 分钟	↓ 75%
代码重复率	35%	21%	↓ 40%
单元测试覆盖率	0%	45%	↑ 45%
Code Review 参与度	30%	95%	↑ 65%

关键成功因素:

自上而下推动: 得到 CTO 支持,分配专门时间
渐进式实施: 不搞大爆炸式改革,小步快跑
工具自动化: 减少人为因素,降低执行成本
正向激励: 表扬优秀实践,而不是惩罚犯错
文化塑造: 让团队意识到"质量"和"速度"不矛盾

最佳实践总结

技术 Leader 的核心能力

能力	说明	重要性
平衡能力	业务需求 vs 技术追求	⭐⭐⭐⭐⭐
推动能力	让规范落地而不是挂在墙上	⭐⭐⭐⭐⭐
沟通能力	向上争取资源,向下传递价值	⭐⭐⭐⭐
自动化思维	用工具解决问题,而不是靠人	⭐⭐⭐⭐⭐
同理心	理解团队成员的困难	⭐⭐⭐⭐

技术债务管理原则

可视化: 技术债务清单公开透明
优先级: 用 P0-P3 分级,先解决高风险问题
ROI 导向: 优先修复"收益高、成本低"的债务
持续投入: 每个迭代预留 20% 时间,而不是"攒着"一次性还
防患未然: 新代码高标准,避免制造新债务

团队规范落地三板斧

工具化: ESLint/Prettier/Husky 自动化检查
流程化: Git Hooks + CI 流水线卡点
文化化: Code Review 成为团队习惯

避坑指南

坑	后果	正确做法
技术完美主义	业务需求延期,团队失去信任	技术投入控制在 20% 以内
一刀切推广	团队抵触,执行不下去	先试点,再推广,最后强制
只写文档不落地	规范成为"空中楼阁"	用 Git Hooks 强制执行
Code Review 走形式	质量不升反降,浪费时间	制定 Checklist,建立激励机制
忽视团队感受	优秀成员流失	多倾听反馈,调整策略

扩展阅读

9.微前端架构设计 - 标准答案

Wed, 21 Jan 2026 07:23:00 GMT

题目

考察点：架构能力、技术选型、问题解决

场景描述：
您的公司有多个前端团队,分别负责不同的业务模块(订单、库存、财务、用户中心),技术栈混杂(Vue2、Vue3、React)。现在需要将这些模块整合到一个统一的后台管理系统中。

需求：

各模块独立开发、独立部署
支持 Vue2、Vue3 混合运行
共享公共依赖(如 Vue、Element UI)以减小包体积
主应用负责路由、权限、布局

问题：

技术方案：微前端的实现方案有哪些？(如 qiankun、Micro-App、Module Federation、iframe)您会选择哪个？为什么？
核心挑战：微前端架构的核心技术难点是什么？(如 JS 沙箱隔离、样式隔离、应用间通信)如何解决？
实战考量：Vue2 和 Vue3 共存时有什么注意事项？如何避免版本冲突？

标准答案

1. 微前端技术方案对比与选型

主流方案对比

方案	技术原理	优点	缺点	适用场景
qiankun	基于 single-spa + HTML Entry + JS 沙箱	成熟稳定、开箱即用、社区活跃、完善的沙箱和样式隔离	性能开销较大、对子应用侵入性中等	企业级中后台系统、多团队协作
Micro-App	基于 WebComponent + HTML Entry	接入成本低、类似 iframe 的使用体验、性能较好	社区相对小、浏览器兼容性依赖 polyfill	快速接入、中小型项目
Module Federation	Webpack 5 原生支持、模块联邦	性能最优、可共享依赖、Webpack 生态	需要 Webpack 5、配置复杂、依赖版本管理难	同技术栈、深度集成场景
iframe	浏览器原生隔离	完全隔离、接入成本极低	性能差、通信复杂、用户体验不佳(白屏、路由不同步)	快速集成第三方系统、安全要求极高

推荐选型：qiankun

理由：

成熟度高：阿里开源,经过蚂蚁集团大规模实践验证
多框架支持：原生支持 Vue2/Vue3/React 等任意框架混用
沙箱隔离：提供 Proxy 沙箱和快照沙箱,有效隔离 JS 运行环境
样式隔离：支持 Shadow DOM 和动态样式表隔离
开箱即用：提供完整的生命周期钩子和应用间通信方案
社区生态：文档完善,issue 响应快,插件丰富

对于 Vue2/Vue3 混用场景,qiankun 是目前最佳选择。

2. 核心技术挑战与解决方案

2.1 JS 沙箱隔离

挑战：多个子应用运行在同一个 window 上下文,可能互相污染全局变量。

qiankun 的解决方案：

a) Proxy 沙箱 (推荐,适用于现代浏览器)

// qiankun 内部实现原理简化版
class ProxySandbox {
  constructor() {
    const fakeWindow = {}
    const proxy = new Proxy(fakeWindow, {
      get(target, prop) {
        // 优先从沙箱中获取
        if (prop in target) {
          return target[prop]
        }
        // 否则从真实 window 获取
        const value = window[prop]
        // 如果是函数,绑定到真实 window
        if (typeof value === 'function' && !value.prototype) {
          return value.bind(window)
        }
        return value
      },
      set(target, prop, value) {
        // 所有修改都记录在沙箱内
        target[prop] = value
        return true
      },
      has(target, prop) {
        return prop in target || prop in window
      }
    })
    
    this.proxy = proxy
  }
  
  // 激活沙箱
  active() {
    this.running = true
  }
  
  // 失活沙箱
  inactive() {
    this.running = false
  }
}

// 使用示例
const sandbox = new ProxySandbox()
sandbox.active()

// 子应用在沙箱中运行
;(function(window) {
  window.myApp = { name: 'App1' } // 只作用于沙箱
})(sandbox.proxy)

sandbox.inactive()

特性：

每个子应用独立 Proxy 沙箱
不影响真实 window
支持多应用同时运行

b) 快照沙箱 (兼容 IE,但不支持多应用并行)

class SnapshotSandbox {
  constructor() {
    this.modifyPropsMap = {} // 记录运行时修改的属性
  }
  
  active() {
    // 保存当前 window 快照
    this.windowSnapshot = {}
    for (const prop in window) {
      this.windowSnapshot[prop] = window[prop]
    }
    
    // 恢复上次记录的修改
    Object.keys(this.modifyPropsMap).forEach(prop => {
      window[prop] = this.modifyPropsMap[prop]
    })
  }
  
  inactive() {
    // 记录本次运行的修改
    for (const prop in window) {
      if (window[prop] !== this.windowSnapshot[prop]) {
        this.modifyPropsMap[prop] = window[prop]
        // 还原 window
        window[prop] = this.windowSnapshot[prop]
      }
    }
  }
}

2.2 样式隔离

挑战：不同子应用的样式可能相互覆盖(如都有 .btn 类)。

解决方案：

a) Shadow DOM (严格隔离,但可能影响弹窗组件)

// qiankun 配置
import { start } from 'qiankun'

start({
  sandbox: {
    strictStyleIsolation: true // 启用 Shadow DOM
  }
})

原理：将子应用渲染在 Shadow DOM 内,样式天然隔离。

注意事项：

Element UI / Ant Design 的弹窗组件默认挂载到 body,可能渲染到 Shadow DOM 外
需要配置弹窗挂载点：

// 子应用配置 Element UI
import { Message } from 'element-ui'

export async function mount(props) {
  const { container } = props
  // 将弹窗挂载到子应用容器内
  Message.config({
    getContainer: () => container.querySelector('#app')
  })
}

b) 动态样式表作用域 (推荐,兼容性好)

start({
  sandbox: {
    experimentalStyleIsolation: true // 运行时添加样式前缀
  }
})

原理：qiankun 运行时动态给子应用的样式选择器添加 data-qiankun 属性前缀。

/* 原始样式 */
.btn { color: red; }

/* qiankun 运行时转换为 */
div[data-qiankun="app1"] .btn { color: red; }

c) CSS Modules / CSS-in-JS (源头隔离)

<!-- Vue 组件使用 scoped 样式 -->
<style scoped>
.btn {
  color: blue;
}
</style>

编译后自动添加唯一哈希：

.btn[data-v-f3f3eg9] {
  color: blue;
}

2.3 应用间通信

挑战：主应用和子应用、子应用之间需要共享数据(如用户信息、token)。

解决方案：

a) qiankun 官方通信方案 - initGlobalState

// ===== 主应用 =====
import { initGlobalState } from 'qiankun'

// 初始化全局状态
const actions = initGlobalState({
  user: { name: 'Admin', token: 'xxx' },
  theme: 'dark'
})

// 监听变化
actions.onGlobalStateChange((state, prev) => {
  console.log('主应用监听到状态变化:', state)
})

// 修改状态
actions.setGlobalState({ theme: 'light' })

// ===== 子应用 =====
export async function mount(props) {
  // 接收主应用传递的通信方法
  props.onGlobalStateChange((state, prev) => {
    console.log('子应用监听到状态变化:', state)
    // 同步到 Vuex/Pinia
    store.commit('setUser', state.user)
  })
  
  // 子应用也可以修改全局状态
  props.setGlobalState({ theme: 'blue' })
}

b) 自定义事件总线 (更灵活)

// ===== 主应用 =====
class EventBus {
  constructor() {
    this.events = {}
  }
  
  on(event, callback) {
    if (!this.events[event]) {
      this.events[event] = []
    }
    this.events[event].push(callback)
  }
  
  emit(event, data) {
    if (this.events[event]) {
      this.events[event].forEach(cb => cb(data))
    }
  }
  
  off(event, callback) {
    if (this.events[event]) {
      this.events[event] = this.events[event].filter(cb => cb !== callback)
    }
  }
}

const eventBus = new EventBus()

registerMicroApps([
  {
    name: 'app1',
    entry: '//localhost:8081',
    container: '#container',
    props: { eventBus } // 传递给子应用
  }
])

// ===== 子应用 =====
export async function mount(props) {
  const { eventBus } = props
  
  // 监听事件
  eventBus.on('user:login', (user) => {
    console.log('用户登录:', user)
  })
  
  // 触发事件
  eventBus.emit('order:create', { orderId: 123 })
}

c) 共享 Pinia Store (Vue 专属,推荐)

// ===== 主应用 =====
import { createPinia } from 'pinia'

const pinia = createPinia()
app.use(pinia)

registerMicroApps([
  {
    name: 'app1',
    entry: '//localhost:8081',
    container: '#container',
    props: { pinia } // 传递 Pinia 实例
  }
])

// ===== 子应用 (Vue3) =====
import { defineStore } from 'pinia'

export async function mount(props) {
  const { pinia } = props
  
  // 使用主应用的 Pinia 实例
  const useUserStore = defineStore('user', {
    state: () => ({ name: '', token: '' })
  })
  
  app.use(pinia) // 注入主应用的 Pinia
  
  const userStore = useUserStore(pinia)
  console.log(userStore.name) // 可访问主应用的状态
}

3. Vue2 与 Vue3 共存方案

3.1 核心挑战

全局 API 冲突：Vue2 和 Vue3 都会在 window 上挂载 window.Vue
依赖版本冲突：Element UI (Vue2) vs Element Plus (Vue3)
路由冲突：Vue Router 3 vs Vue Router 4

3.2 解决方案

a) 通过 qiankun 沙箱隔离

// 主应用使用 Vue3
import { createApp } from 'vue'
import App from './App.vue'

createApp(App).mount('#main-app')

// 注册 Vue2 子应用
registerMicroApps([
  {
    name: 'vue2-app',
    entry: '//localhost:8081',
    container: '#subapp-container',
    activeRule: '/vue2'
  }
])

// 注册 Vue3 子应用
registerMicroApps([
  {
    name: 'vue3-app',
    entry: '//localhost:8082',
    container: '#subapp-container',
    activeRule: '/vue3'
  }
])

start({
  sandbox: {
    strictStyleIsolation: false,
    experimentalStyleIsolation: true
  }
})

qiankun 的沙箱会自动隔离：

Vue2 子应用的 window.Vue 不会影响 Vue3
两个子应用的路由实例互不干扰

b) 子应用配置 (Vue2 子应用示例)

// ===== Vue2 子应用入口文件 =====
import Vue from 'vue'
import VueRouter from 'vue-router'
import ElementUI from 'element-ui'
import 'element-ui/lib/theme-chalk/index.css'
import App from './App.vue'

Vue.use(VueRouter)
Vue.use(ElementUI)

let instance = null
let router = null

// 导出 qiankun 生命周期
export async function bootstrap() {
  console.log('Vue2 子应用 bootstrap')
}

export async function mount(props) {
  console.log('Vue2 子应用 mount', props)
  
  // 创建路由实例
  router = new VueRouter({
    mode: 'history',
    base: window.__POWERED_BY_QIANKUN__ ? '/vue2' : '/',
    routes: [
      { path: '/order', component: () => import('./views/Order.vue') }
    ]
  })
  
  // 创建 Vue 实例
  instance = new Vue({
    router,
    render: h => h(App)
  }).$mount(props.container ? props.container.querySelector('#app') : '#app')
}

export async function unmount() {
  instance.$destroy()
  instance.$el.innerHTML = ''
  instance = null
  router = null
}

// 独立运行时直接挂载
if (!window.__POWERED_BY_QIANKUN__) {
  mount({})
}

c) 依赖共享与隔离

推荐策略：

公共依赖不共享：Vue2 和 Vue3 各自打包,避免版本冲突
工具库可共享：如 axios、lodash 可通过 externals 配置共享

// Vue2 子应用 vue.config.js
module.exports = {
  configureWebpack: {
    externals: {
      // axios 共享,从主应用加载
      axios: 'axios'
    },
    output: {
      library: 'vue2App',
      libraryTarget: 'umd',
      jsonpFunction: `webpackJsonp_vue2App` // 避免 chunk 冲突
    }
  }
}

// 主应用 index.html 提供共享依赖
<script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script>

3.3 最佳实践清单

实践	说明	重要性
避免全局污染	子应用不要在 window 上挂载变量	⭐⭐⭐⭐⭐
路由 base 配置	子应用路由 base 需根据运行环境动态设置	⭐⭐⭐⭐⭐
静态资源 publicPath	配置 `__webpack_public_path__` 为动态值	⭐⭐⭐⭐⭐
弹窗组件挂载点	确保弹窗渲染在子应用容器内	⭐⭐⭐⭐
生命周期规范	必须导出 `bootstrap/mount/unmount`	⭐⭐⭐⭐⭐
独立运行能力	子应用需支持脱离 qiankun 独立运行	⭐⭐⭐⭐

// 动态 publicPath 配置
if (window.__POWERED_BY_QIANKUN__) {
  __webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__
}

4. 完整方案架构示例

┌─────────────────────────────────────────────────┐
│               主应用 (Vue3)                      │
│  - 路由控制、权限管理、全局布局                    │
│  - qiankun 加载器                                │
│  - 公共组件库、工具函数                            │
└──────────────┬──────────────────────────────────┘
               │
      ┌────────┼────────┬────────┐
      │        │        │        │
┌─────▼───┐ ┌─▼─────┐ ┌▼──────┐ ┌▼──────────┐
│ Vue2    │ │ Vue3  │ │ React │ │ Angular   │
│ 订单模块 │ │ 库存  │ │ 财务  │ │ 用户中心  │
│         │ │ 模块  │ │ 模块  │ │           │
│ Element │ │ Elem+ │ │ AntD  │ │ Material  │
│ UI      │ │       │ │       │ │           │
└─────────┘ └───────┘ └───────┘ └───────────┘

主应用配置：

// main.ts
import { registerMicroApps, start, initGlobalState } from 'qiankun'
import { createPinia } from 'pinia'

const pinia = createPinia()

// 初始化全局状态
const actions = initGlobalState({
  user: null,
  token: localStorage.getItem('token')
})

// 注册子应用
registerMicroApps([
  {
    name: 'order-app',
    entry: '//localhost:8081', // Vue2
    container: '#subapp-viewport',
    activeRule: '/order',
    props: { pinia, actions }
  },
  {
    name: 'stock-app',
    entry: '//localhost:8082', // Vue3
    container: '#subapp-viewport',
    activeRule: '/stock',
    props: { pinia, actions }
  },
  {
    name: 'finance-app',
    entry: '//localhost:8083', // React
    container: '#subapp-viewport',
    activeRule: '/finance',
    props: { actions }
  }
], {
  beforeLoad: app => console.log('加载前', app.name),
  beforeMount: app => console.log('挂载前', app.name),
  afterMount: app => console.log('挂载后', app.name),
  beforeUnmount: app => console.log('卸载前', app.name),
  afterUnmount: app => console.log('卸载后', app.name)
})

// 启动 qiankun
start({
  sandbox: {
    strictStyleIsolation: false,
    experimentalStyleIsolation: true
  },
  prefetch: 'all', // 预加载所有子应用
  fetch: (url, ...args) => {
    // 自定义 fetch,可添加 token
    return window.fetch(url, {
      ...args,
      headers: {
        ...args[0]?.headers,
        'Authorization': `Bearer ${localStorage.getItem('token')}`
      }
    })
  }
})

最佳实践总结

技术选型建议

场景	推荐方案	原因
多团队、多技术栈	qiankun	成熟、支持任意框架混用
同技术栈、深度集成	Module Federation	性能最优、原生支持依赖共享
快速接入、中小项目	Micro-App	使用简单、接入成本低
集成第三方系统	iframe	完全隔离、安全性高

实施要点

渐进式改造：先从边缘模块试点,积累经验后再推广
文档先行：制定《微前端接入规范》,明确生命周期、通信方式、样式规范
基建工具：提供子应用脚手架、公共组件库、部署脚本
监控告警：接入性能监控(子应用加载时间、错误上报)
灰度发布：支持子应用独立灰度,降低上线风险

常见坑点

问题	原因	解决方案
路由切换后子应用白屏	未正确实现 unmount	确保 unmount 中销毁实例、清空 DOM
弹窗显示在错误位置	弹窗挂载到 body 外	配置弹窗 getContainer 指向子应用容器
样式丢失	publicPath 配置错误	动态设置 `__webpack_public_path__`
子应用间数据不同步	未使用全局状态管理	使用 qiankun 的 initGlobalState 或共享 Pinia
Vue2/Vue3 冲突	沙箱未生效	检查 qiankun 版本、确保启用沙箱

扩展阅读

8.Node.js 性能调优 - 标准答案

Wed, 21 Jan 2026 07:22:00 GMT

题目

Node.js 性能调优：如何分析和优化 Node.js 应用的性能？

标准答案

1. 性能分析工具

CPU 分析：

# 使用 --cpu-prof 生成 CPU profile
node --cpu-prof app.js

# 使用 Clinic.js
npm install -g clinic
clinic doctor -- node app.js  # 诊断性能问题
clinic flame -- node app.js   # 生成火焰图

内存分析：

# 生成 Heap Snapshot
node --inspect app.js
# Chrome DevTools → Memory → Take snapshot

# 使用 heapdump
const heapdump = require('heapdump')
heapdump.writeSnapshot('./heap-' + Date.now() + '.heapsnapshot')

2. 常见性能问题

问题1：同步代码阻塞

// ❌ 同步读文件阻塞 Event Loop
const data = fs.readFileSync('/large-file.txt')

// ✅ 异步读取
const data = await fs.promises.readFile('/large-file.txt')

问题2：未使用连接池

// ❌ 每次都创建新连接
const mysql = require('mysql')
const conn = mysql.createConnection(config)

// ✅ 使用连接池
const pool = mysql.createPool(config)

问题3：内存泄漏

// ❌ 全局变量累积
const cache = {}
app.get('/data/:id', (req, res) => {
  cache[req.params.id] = fetchData(req.params.id)
  res.json(cache[req.params.id])
})

// ✅ 使用 LRU 缓存
const LRU = require('lru-cache')
const cache = new LRU({ max: 500 })

3. 优化策略

集群模式：

const cluster = require('cluster')
const os = require('os')

if (cluster.isMaster) {
  const numCPUs = os.cpus().length
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork()
  }
} else {
  // Worker 进程运行服务器
  require('./app.js')
}

缓存优化：

使用 Redis 缓存热点数据
使用 CDN 缓存静态资源
使用内存缓存（如 LRU）

数据库优化：

添加索引
使用连接池
避免 N+1 查询

最佳实践

使用 PM2 管理进程
启用 Cluster 模式
监控关键指标（CPU、内存、响应时间）
使用缓存策略
优化数据库查询
避免同步代码

扩展阅读

7.Node.js Event Loop - 标准答案

Wed, 21 Jan 2026 07:21:00 GMT

题目

考察点：Node.js 核心原理、事件循环、宏任务微任务

问题：解释 Node.js 的 Event Loop 机制，并说明以下代码的执行顺序：

console.log(1)

setTimeout(() => {
  console.log(2)
  Promise.resolve().then(() => console.log(3))
}, 0)

Promise.resolve().then(() => console.log(4))

setTimeout(() => {
  console.log(5)
}, 0)

console.log(6)

标准答案

正确输出顺序

执行过程详解

执行栈：
1. console.log(1)  → 输出 1
2. setTimeout(..., 0) → 注册宏任务（timers 队列）
3. Promise.resolve().then(...) → 注册微任务
4. setTimeout(..., 0) → 注册宏任务（timers 队列）
5. console.log(6)  → 输出 6

同步代码执行完毕，开始 Event Loop：

第1轮循环：
  - 清空微任务队列：console.log(4) → 输出 4
  - 执行宏任务（timers）：第1个 setTimeout
    - console.log(2) → 输出 2
    - Promise.resolve().then(...) → 注册微任务
  - 清空微任务队列：console.log(3) → 输出 3

第2轮循环：
  - 执行宏任务（timers）：第2个 setTimeout
    - console.log(5) → 输出 5

Event Loop 完整机制

1. Node.js Event Loop 的 6 个阶段

   ┌───────────────────────────┐
┌─>│           timers          │  执行 setTimeout/setInterval 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │  执行延迟到下一轮的 I/O 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │  仅内部使用
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │  执行 setImmediate 回调
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │  执行 socket.on('close', ...) 回调
   └───────────────────────────┘

各阶段说明：

阶段	说明	示例
timers	执行 `setTimeout` 和 `setInterval` 回调	setTimeout(fn, 0)
pending callbacks	执行系统操作的回调（如 TCP 错误）	-
idle, prepare	内部使用	-
poll	获取新的 I/O 事件，执行 I/O 回调	fs.readFile
check	执行 `setImmediate` 回调	setImmediate(fn)
close callbacks	执行 close 事件回调	socket.on('close', fn)

2. 微任务（Microtask）

微任务在每个阶段结束后执行：

// 微任务类型
process.nextTick(callback)  // 优先级最高
Promise.resolve().then(callback)
queueMicrotask(callback)
async/await

执行顺序：

每个宏任务阶段结束后：
1. 清空 process.nextTick 队列
2. 清空 Promise 微任务队列
3. 进入下一个宏任务阶段

3. setTimeout vs setImmediate

// 情况1：在主模块中（非 I/O 回调）
setTimeout(() => console.log('timeout'), 0)
setImmediate(() => console.log('immediate'))

// 输出顺序不确定！
// 原因：setTimeout(fn, 0) 实际是 setTimeout(fn, 1)
//       如果事件循环启动用时 < 1ms，先执行 setImmediate
//       如果事件循环启动用时 >= 1ms，先执行 setTimeout

// 情况2：在 I/O 回调中
const fs = require('fs')

fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0)
  setImmediate(() => console.log('immediate'))
})

// 输出顺序固定：
// immediate
// timeout

// 原因：I/O 回调在 poll 阶段执行
//       setImmediate 在下一个 check 阶段立即执行
//       setTimeout 需要等到下一轮 Event Loop 的 timers 阶段

4. process.nextTick vs Promise

console.log('start')

process.nextTick(() => {
  console.log('nextTick 1')
  process.nextTick(() => {
    console.log('nextTick 2')
  })
})

Promise.resolve().then(() => {
  console.log('promise 1')
  Promise.resolve().then(() => {
    console.log('promise 2')
  })
})

console.log('end')

// 输出顺序：
// start
// end
// nextTick 1
// nextTick 2  ← nextTick 优先级更高，递归执行完
// promise 1
// promise 2

优先级：

process.nextTick > Promise.then > setTimeout > setImmediate

5. 复杂示例分析

console.log('1')

setTimeout(() => {
  console.log('2')
  process.nextTick(() => console.log('3'))
}, 0)

setTimeout(() => {
  console.log('4')
  process.nextTick(() => console.log('5'))
}, 0)

process.nextTick(() => console.log('6'))

console.log('7')

// 输出顺序分析：

// 同步代码：
1, 7

// 第1轮 Event Loop：
// - 微任务（process.nextTick）：
6

// - 宏任务（timers 第1个 setTimeout）：
2
// - 微任务（process.nextTick）：
3

// - 宏任务（timers 第2个 setTimeout）：
4
// - 微任务（process.nextTick）：
5

// 最终输出：
// 1, 7, 6, 2, 3, 4, 5

6. async/await 与 Event Loop

async function async1() {
  console.log('async1 start')
  await async2()
  console.log('async1 end')  // 相当于 Promise.then
}

async function async2() {
  console.log('async2')
}

console.log('script start')

setTimeout(() => {
  console.log('setTimeout')
}, 0)

async1()

new Promise(resolve => {
  console.log('promise1')
  resolve()
}).then(() => {
  console.log('promise2')
})

console.log('script end')

// 输出顺序：
// script start
// async1 start
// async2
// promise1
// script end
// async1 end  ← await 后面的代码进入微任务队列
// promise2
// setTimeout

await 的本质：

// 这段代码：
async function fn() {
  await somePromise()
  console.log('after await')
}

// 等价于：
function fn() {
  return somePromise().then(() => {
    console.log('after await')
  })
}

浏览器 vs Node.js Event Loop

特性	浏览器	Node.js
宏任务	setTimeout、setInterval、I/O、UI 渲染	setTimeout、setImmediate、I/O
微任务	Promise、MutationObserver	Promise、process.nextTick
执行顺序	每次执行 1 个宏任务 → 清空所有微任务	每个阶段执行所有宏任务 → 清空所有微任务
特殊 API	无	`process.nextTick`（优先级最高）

常见面试陷阱

陷阱1：setTimeout(fn, 0) 并非真正的 0ms

setTimeout(() => console.log('timeout'), 0)

// 实际延迟：
// - 浏览器：至少 4ms（HTML5 标准）
// - Node.js：至少 1ms

陷阱2：process.nextTick 可能导致饿死

// ❌ 危险代码
function recursiveNextTick() {
  process.nextTick(recursiveNextTick)
}
recursiveNextTick()

// 问题：nextTick 优先级太高，会一直递归，阻塞 Event Loop
// 其他 I/O 操作永远无法执行

陷阱3：微任务插队

setTimeout(() => {
  console.log('timeout 1')
  Promise.resolve().then(() => console.log('promise'))
  setTimeout(() => console.log('timeout 2'), 0)
}, 0)

// 输出顺序：
// timeout 1
// promise  ← 微任务插队，比 timeout 2 先执行
// timeout 2

最佳实践

理解宏任务和微任务的区别
避免滥用 process.nextTick（可能阻塞 Event Loop）
I/O 回调中优先使用 setImmediate（而非 setTimeout）
长任务分片：避免阻塞 Event Loop

// ❌ 阻塞 Event Loop
for (let i = 0; i < 1e9; i++) {
  // 耗时操作
}

// ✅ 分片处理
function processData(data, batchSize = 1000) {
  let index = 0
  
  function processBatch() {
    const end = Math.min(index + batchSize, data.length)
    
    for (let i = index; i < end; i++) {
      // 处理数据
    }
    
    index = end
    
    if (index < data.length) {
      setImmediate(processBatch)  // 让出 Event Loop
    }
  }
  
  processBatch()
}

使用 Worker Threads 处理 CPU 密集型任务

const { Worker } = require('worker_threads')

const worker = new Worker('./heavy-task.js')
worker.on('message', result => {
  console.log('Result:', result)
})

扩展阅读

6.Nuxt.js SSR 实战 - 标准答案

Wed, 21 Jan 2026 07:20:00 GMT

题目

Nuxt.js SSR 实践：如何处理客户端/服务端差异？如何优化 SSR 性能？

标准答案

1. SSR vs SSG vs CSR

模式	渲染时机	适用场景	性能
SSR	每次请求时渲染	动态内容、SEO	中
SSG	构建时预渲染	静态内容、博客	高
CSR	浏览器渲染	后台管理系统	低

2. 数据获取

// Nuxt3 - useFetch (服务端+客户端都会执行)
const { data: posts } = await useFetch('/api/posts')

// useAsyncData (自定义异步逻辑)
const { data } = await useAsyncData('posts', () => $fetch('/api/posts'))

// 仅客户端执行
onMounted(() => {
  // 访问 window, document 等
})

3. 环境判断

<template>
  <!-- 仅客户端渲染 -->
  <ClientOnly>
    <Chart />  <!-- 依赖 window 的组件 -->
  </ClientOnly>
</template>

<script setup>
// 判断环境
if (import.meta.server) {
  // 服务端逻辑
}

if (import.meta.client) {
  // 客户端逻辑
}
</script>

4. 常见问题

问题1：水合不匹配（Hydration Mismatch）

// ❌ 错误：服务端和客户端渲染结果不同
<div>{{ new Date().getTime() }}</div>  // 时间戳每次都不同

// ✅ 正确：使用 ClientOnly 或统一数据源
<ClientOnly>
  <div>{{ timestamp }}</div>
</ClientOnly>

问题2：window/document 未定义

// ❌ 错误：服务端没有 window
const width = window.innerWidth

// ✅ 正确：判断环境或使用 ClientOnly
const width = import.meta.client ? window.innerWidth : 0

5. 性能优化

// 1. 缓存策略
const { data } = await useFetch('/api/posts', {
  getCachedData(key) {
    return nuxtApp.payload.data[key] || nuxtApp.static.data[key]
  }
})

// 2. 懒加载组件
const HeavyComponent = defineAsyncComponent(() =>
  import('~/components/HeavyComponent.vue')
)

// 3. 路由缓存
export default defineNuxtConfig({
  routeRules: {
    '/blog/**': { swr: 3600 },  // 1小时缓存
    '/admin/**': { ssr: false }  // 客户端渲染
  }
})

最佳实践

合理选择渲染模式：SEO 需求用 SSR，静态内容用 SSG
处理环境差异：用 ClientOnly 包裹客户端组件
避免水合错误：确保服务端和客户端渲染结果一致
缓存优化：合理使用页面缓存和 API 缓存
监控性能：使用 Lighthouse 和 WebPageTest

扩展阅读

5.Vue Diff 算法 - 标准答案

Wed, 21 Jan 2026 07:19:00 GMT

题目

考察点：核心原理、算法理解、性能优化

问题：
Vue 的虚拟 DOM Diff 算法是如何工作的？Vue2 和 Vue3 的 Diff 算法有什么区别？为什么需要 key？

标准答案

1. Diff 算法基本原理

为什么需要 Diff 算法？

// 直接操作 DOM 成本很高
const list = document.querySelector('#list')
list.innerHTML = ''  // 清空
data.forEach(item => {
  const li = document.createElement('li')
  li.textContent = item
  list.appendChild(li)  // 每次都操作 DOM
})

// 虚拟 DOM + Diff 算法
// 1. 对比新旧虚拟 DOM 树
// 2. 找出最小差异
// 3. 只更新变化的部分

核心思想：

同层比较：只比较同一层级的节点（时间复杂度 O(n)）
类型判断：不同类型直接替换
key 标识：快速定位可复用节点

2. Vue2 的 Diff 算法（双端对比）

算法流程

旧节点：A B C D
新节点：B A D C

步骤1：双端对比
  旧头 A  ←→  新头 B  ❌
  旧尾 D  ←→  新尾 C  ❌
  旧头 A  ←→  新尾 C  ❌
  旧尾 D  ←→  新头 B  ❌

步骤2：通过 key 查找
  新头 B 在旧节点中找到，移动 B

步骤3：继续双端对比
  ...

源码简化版

function updateChildren(oldCh, newCh) {
  let oldStartIdx = 0
  let oldEndIdx = oldCh.length - 1
  let newStartIdx = 0
  let newEndIdx = newCh.length - 1
  
  let oldStartVnode = oldCh[0]
  let oldEndVnode = oldCh[oldEndIdx]
  let newStartVnode = newCh[0]
  let newEndVnode = newCh[newEndIdx]
  
  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    // 跳过已处理的节点
    if (!oldStartVnode) {
      oldStartVnode = oldCh[++oldStartIdx]
    } else if (!oldEndVnode) {
      oldEndVnode = oldCh[--oldEndIdx]
    }
    
    // 四种快速匹配
    else if (sameVnode(oldStartVnode, newStartVnode)) {
      // 旧头 vs 新头
      patchVnode(oldStartVnode, newStartVnode)
      oldStartVnode = oldCh[++oldStartIdx]
      newStartVnode = newCh[++newStartIdx]
    }
    else if (sameVnode(oldEndVnode, newEndVnode)) {
      // 旧尾 vs 新尾
      patchVnode(oldEndVnode, newEndVnode)
      oldEndVnode = oldCh[--oldEndIdx]
      newEndVnode = newCh[--newEndIdx]
    }
    else if (sameVnode(oldStartVnode, newEndVnode)) {
      // 旧头 vs 新尾（节点右移）
      patchVnode(oldStartVnode, newEndVnode)
      nodeOps.insertBefore(parentElm, oldStartVnode.elm, nodeOps.nextSibling(oldEndVnode.elm))
      oldStartVnode = oldCh[++oldStartIdx]
      newEndVnode = newCh[--newEndIdx]
    }
    else if (sameVnode(oldEndVnode, newStartVnode)) {
      // 旧尾 vs 新头（节点左移）
      patchVnode(oldEndVnode, newStartVnode)
      nodeOps.insertBefore(parentElm, oldEndVnode.elm, oldStartVnode.elm)
      oldEndVnode = oldCh[--oldEndIdx]
      newStartVnode = newCh[++newStartIdx]
    }
    
    // 都不匹配，通过 key 查找
    else {
      const idxInOld = findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx)
      if (!idxInOld) {
        // 新节点，创建
        createElm(newStartVnode, parentElm, oldStartVnode.elm)
      } else {
        // 找到了，移动复用
        const vnodeToMove = oldCh[idxInOld]
        patchVnode(vnodeToMove, newStartVnode)
        oldCh[idxInOld] = undefined
        nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
      }
      newStartVnode = newCh[++newStartIdx]
    }
  }
  
  // 处理剩余节点
  if (oldStartIdx > oldEndIdx) {
    // 新节点有剩余，批量添加
    addVnodes(parentElm, newCh, newStartIdx, newEndIdx)
  } else if (newStartIdx > newEndIdx) {
    // 旧节点有剩余，批量删除
    removeVnodes(parentElm, oldCh, oldStartIdx, oldEndIdx)
  }
}

特点：

✅ 双端对比，4 种快速匹配
✅ 适合头尾操作（push、pop、shift、unshift）
❌ 中间插入需要遍历查找

3. Vue3 的 Diff 算法（最长递增子序列）

核心优化

Vue3 算法分 5 个步骤：

旧节点：A B C D E
新节点：B A D C F

步骤1：前序对比（从头开始）
  A ≠ B，停止

步骤2：后序对比（从尾开始）
  E ≠ F，停止

步骤3：处理新增/删除
  如果旧节点遍历完，新节点有剩余 → 新增
  如果新节点遍历完，旧节点有剩余 → 删除

步骤4：处理未知序列（最长递增子序列）
  旧节点：B C D
  新节点：B D C
  
  找到最长递增子序列：B D
  只需移动 C，复用 B 和 D

步骤5：移动节点
  移动非递增序列的节点

最长递增子序列算法

// 找出最长递增子序列的索引
function getSequence(arr) {
  const p = arr.slice()  // 保存前驱索引
  const result = [0]
  let i, j, u, v, c
  const len = arr.length
  
  for (i = 0; i < len; i++) {
    const arrI = arr[i]
    
    if (arrI !== 0) {
      j = result[result.length - 1]
      
      // 如果当前值大于结果序列的最后一个，直接push
      if (arr[j] < arrI) {
        p[i] = j
        result.push(i)
        continue
      }
      
      // 二分查找，找到第一个比 arrI 大的位置，替换它
      u = 0
      v = result.length - 1
      while (u < v) {
        c = (u + v) >> 1  // 中间位置
        if (arr[result[c]] < arrI) {
          u = c + 1
        } else {
          v = c
        }
      }
      
      if (arrI < arr[result[u]]) {
        if (u > 0) {
          p[i] = result[u - 1]
        }
        result[u] = i
      }
    }
  }
  
  // 回溯找到正确的序列
  u = result.length
  v = result[u - 1]
  while (u-- > 0) {
    result[u] = v
    v = p[v]
  }
  
  return result
}

// 示例
const arr = [0, 8, 4, 12, 2, 10, 6, 14, 1, 9, 5, 13, 3, 11, 7, 15]
console.log(getSequence(arr))
// 输出最长递增子序列的索引位置

Vue3 Diff 源码简化

function patchKeyedChildren(c1, c2, container) {
  let i = 0
  const l2 = c2.length
  let e1 = c1.length - 1  // 旧子节点末尾索引
  let e2 = l2 - 1  // 新子节点末尾索引
  
  // 1. 前序对比
  while (i <= e1 && i <= e2) {
    const n1 = c1[i]
    const n2 = c2[i]
    if (isSameVNodeType(n1, n2)) {
      patch(n1, n2, container)
    } else {
      break
    }
    i++
  }
  
  // 2. 后序对比
  while (i <= e1 && i <= e2) {
    const n1 = c1[e1]
    const n2 = c2[e2]
    if (isSameVNodeType(n1, n2)) {
      patch(n1, n2, container)
    } else {
      break
    }
    e1--
    e2--
  }
  
  // 3. 新节点有剩余（新增）
  if (i > e1) {
    if (i <= e2) {
      while (i <= e2) {
        patch(null, c2[i], container)
        i++
      }
    }
  }
  
  // 4. 旧节点有剩余（删除）
  else if (i > e2) {
    while (i <= e1) {
      unmount(c1[i])
      i++
    }
  }
  
  // 5. 处理未知序列（最长递增子序列）
  else {
    const s1 = i
    const s2 = i
    
    // 5.1 建立新节点的 key -> index 映射
    const keyToNewIndexMap = new Map()
    for (i = s2; i <= e2; i++) {
      const nextChild = c2[i]
      keyToNewIndexMap.set(nextChild.key, i)
    }
    
    // 5.2 遍历旧节点，找出需要移动和删除的节点
    let patched = 0
    const toBePatched = e2 - s2 + 1
    let moved = false
    let maxNewIndexSoFar = 0
    const newIndexToOldIndexMap = new Array(toBePatched).fill(0)
    
    for (i = s1; i <= e1; i++) {
      const prevChild = c1[i]
      
      if (patched >= toBePatched) {
        // 新节点都处理完了，剩下的都是要删除的
        unmount(prevChild)
        continue
      }
      
      let newIndex = keyToNewIndexMap.get(prevChild.key)
      
      if (newIndex === undefined) {
        // 旧节点在新节点中不存在，删除
        unmount(prevChild)
      } else {
        // 记录新旧节点的映射关系
        newIndexToOldIndexMap[newIndex - s2] = i + 1
        
        // 判断是否需要移动
        if (newIndex >= maxNewIndexSoFar) {
          maxNewIndexSoFar = newIndex
        } else {
          moved = true
        }
        
        // 复用节点
        patch(prevChild, c2[newIndex], container)
        patched++
      }
    }
    
    // 5.3 移动和挂载新节点
    const increasingNewIndexSequence = moved
      ? getSequence(newIndexToOldIndexMap)
      : []
    
    let j = increasingNewIndexSequence.length - 1
    
    // 倒序遍历，方便插入
    for (i = toBePatched - 1; i >= 0; i--) {
      const nextIndex = s2 + i
      const nextChild = c2[nextIndex]
      const anchor = nextIndex + 1 < l2 ? c2[nextIndex + 1].el : null
      
      if (newIndexToOldIndexMap[i] === 0) {
        // 新节点，挂载
        patch(null, nextChild, container, anchor)
      } else if (moved) {
        // 需要移动
        if (j < 0 || i !== increasingNewIndexSequence[j]) {
          move(nextChild, container, anchor)
        } else {
          j--
        }
      }
    }
  }
}

4. key 的作用

为什么需要 key？

<!-- ❌ 没有 key -->
<li v-for="item in items">{{ item.name }}</li>

<!-- 新旧列表 -->
旧：[{ name: 'A' }, { name: 'B' }, { name: 'C' }]
新：[{ name: 'B' }, { name: 'C' }, { name: 'A' }]

<!-- Diff 结果：就地复用，修改所有节点的文本内容 -->
1. 修改第1个 li 的文本：A → B
2. 修改第2个 li 的文本：B → C
3. 修改第3个 li 的文本：C → A
效率低！


<!-- ✅ 有 key -->
<li v-for="item in items" :key="item.id">{{ item.name }}</li>

<!-- Diff 结果：通过 key 识别，只移动节点 -->
1. 复用 B 节点，移动到第1位
2. 复用 C 节点，移动到第2位
3. 复用 A 节点，移动到第3位
效率高！

key 的最佳实践：

<!-- ✅ 好：使用唯一 ID -->
<li v-for="item in users" :key="item.id">{{ item.name }}</li>

<!-- ❌ 不好：使用 index -->
<li v-for="(item, index) in users" :key="index">{{ item.name }}</li>
<!-- 问题：删除第1项后，所有 index 都变了，无法复用 -->

<!-- ❌ 不好：使用随机数 -->
<li v-for="item in users" :key="Math.random()">{{ item.name }}</li>
<!-- 问题：每次渲染 key 都不同，永远无法复用 -->

不使用 key 的副作用：

<template>
  <div v-for="(item, index) in list" :key="index">
    <input v-model="item.value" />
  </div>
</template>

<script setup>
const list = ref([
  { id: 1, value: 'A' },
  { id: 2, value: 'B' },
  { id: 3, value: 'C' }
])

// 删除第1项
function removeFirst() {
  list.value.shift()
}
</script>

<!-- 问题：
删除第1项后：
  原本 index=0 的 input（值为'A'）被删除
  原本 index=1 的 input 变成 index=0（但值仍为'B'）
  原本 index=2 的 input 变成 index=1（但值仍为'C'）
  
  Vue 会复用 DOM，导致 input 的值错位！
-->

<!-- 解决：使用唯一 ID -->
<div v-for="item in list" :key="item.id">
  <input v-model="item.value" />
</div>

5. Vue2 vs Vue3 Diff 对比

特性	Vue2	Vue3
算法	双端对比	最长递增子序列
时间复杂度	O(n)	O(n log n)
移动次数	较多	最少（理论最优）
适合场景	头尾操作	任意位置插入/删除
静态标记	无	PatchFlag 静态提升

性能测试：

场景：1000个节点，随机插入/删除

Vue2：需要移动 ~500 个节点
Vue3：需要移动 ~100 个节点（找到最长递增子序列，只移动非递增的）

结果：Vue3 性能提升 5倍

最佳实践

始终使用唯一且稳定的 key
不要使用 index 作为 key（除非列表完全静态）
不要使用随机数作为 key
不要省略 key（虽然 Vue 不报错，但性能差）
理解 Diff 算法原理，写出高性能的列表代码

扩展阅读

4.Vue2 迁移到 Vue3 - 标准答案

Wed, 21 Jan 2026 07:18:00 GMT

题目

Vue2 到 Vue3 迁移策略：10万+ 行代码的大型项目如何平滑迁移？

标准答案

渐进式迁移策略

阶段1：准备阶段

升级到 Vue 2.7（过渡版本，支持部分 Vue3 API）
使用 ESLint 插件检测不兼容代码
建立完善的测试覆盖

阶段2：使用 @vue/compat

// vite.config.js
export default {
  resolve: {
    alias: {
      vue: '@vue/compat'
    }
  }
}

阶段3：逐模块迁移

从独立模块开始（如工具函数、公共组件）
修改不兼容 API
建立 MVP 回归测试

阶段4：去除兼容层

逐步移除 @vue/compat
启用 Vue3 完整特性

常见不兼容 API

Vue2	Vue3 替代
`this.$children`	`ref()` + `expose()`
`this.$listeners`	合并到 `$attrs`
EventBus	mitt 或 Pinia
`$on/$off/$once`	已移除，用 mitt
Filters	方法或计算属性

最佳实践

使用自动化工具：gogocode、vue-codemod
建立测试保障：单元测试 + E2E 测试
灰度发布：先上线小流量观察
性能监控：对比迁移前后性能数据

扩展阅读

3.Vue3 性能优化 - 标准答案

Wed, 21 Jan 2026 07:17:00 GMT

题目

考察点：性能调优、内存管理、渲染优化、实战能力

场景描述：
优化一个 Vue3 的数据可视化大屏项目：

实时展示 5000+ 条设备状态数据（每秒更新 50-100 条）
页面包含多个图表组件（ECharts）、表格、卡片
首屏加载时间 8秒+，滚动时有明显卡顿
内存占用持续增长，1小时后页面变慢

问题：

渲染优化：除虚拟滚动外，Vue3 还有哪些优化大数据列表的手段？
组件优化：如何优化频繁更新的图表组件？
内存泄漏：如何排查并解决 Vue3 应用中的内存泄漏？
首屏优化：针对 8秒+ 的首屏时间，有哪些优化方案？

标准答案

1. 渲染优化

核心手段：

// 1. shallowRef - 浅层响应式（只追踪 .value 变化）
import { shallowRef } from 'vue'

const largeList = shallowRef([/* 5000+ 条数据 */])

// 更新数据时手动触发更新
function updateList(newData) {
  largeList.value = [...newData]  // 整体替换才会触发更新
}

// 2. shallowReactive - 只代理第一层
const state = shallowReactive({
  items: [/* 大数组 */]
})

// 3. v-memo - 缓存组件渲染结果
<template>
  <div v-for="item in list" :key="item.id" v-memo="[item.status]">
    <!-- 只有 item.status 变化时才重新渲染 -->
    <DeviceCard :data="item" />
  </div>
</template>

// 4. v-once - 只渲染一次
<div v-once>
  <!-- 静态内容，永不更新 -->
  <StaticChart />
</div>

// 5. 虚拟滚动
import { useVirtualList } from '@vueuse/core'

const { list: virtualList, containerProps, wrapperProps } = useVirtualList(
  largeList,
  { itemHeight: 80, overscan: 10 }
)

2. 组件优化

图表组件防抖节流：

import { debounce } from 'lodash-es'
import * as echarts from 'echarts/core'

export default {
  setup() {
    const chartRef = ref()
    let chartInstance = null
    
    // 防抖更新图表
    const updateChart = debounce((data) => {
      if (!chartInstance) {
        chartInstance = echarts.init(chartRef.value)
      }
      
      chartInstance.setOption({
        series: [{ data }]
      })
    }, 300)
    
    // WebSocket 数据流
    onMounted(() => {
      const ws = new WebSocket('ws://...')
      ws.onmessage = (event) => {
        const newData = JSON.parse(event.data)
        updateChart(newData)  // 自动防抖
      }
      
      onUnmounted(() => {
        ws.close()
        chartInstance?.dispose()  // 释放图表实例
      })
    })
    
    return { chartRef }
  }
}

组件缓存：

<template>
  <!-- 缓存不活跃的标签页 -->
  <KeepAlive :max="5">
    <component :is="currentTab" />
  </KeepAlive>
</template>

3. 内存泄漏排查

常见泄漏点：

// ❌ 问题1：定时器未清理
export default {
  setup() {
    const timer = setInterval(() => {
      // ...
    }, 1000)
    
    // ✅ 解决：清理定时器
    onUnmounted(() => {
      clearInterval(timer)
    })
  }
}

// ❌ 问题2：全局事件未解绑
export default {
  setup() {
    const handleResize = () => { /* ... */ }
    
    onMounted(() => {
      window.addEventListener('resize', handleResize)
    })
    
    // ✅ 解决：解绑事件
    onUnmounted(() => {
      window.removeEventListener('resize', handleResize)
    })
  }
}

// ❌ 问题3：第三方库实例未销毁
export default {
  setup() {
    let chart = null
    
    onMounted(() => {
      chart = echarts.init(chartRef.value)
    })
    
    // ✅ 解决：销毁实例
    onUnmounted(() => {
      chart?.dispose()
      chart = null
    })
  }
}

排查工具：

Chrome DevTools - Memory
- 录制堆快照（Heap Snapshot）
- 对比快照找泄漏点
- 查看 Detached DOM nodes
Vue DevTools
- 查看组件树
- 检查未清理的组件实例

4. 首屏优化

优化策略：

// 1. 路由懒加载
const routes = [
  {
    path: '/dashboard',
    component: () => import('./views/Dashboard.vue')  // 懒加载
  }
]

// 2. 组件懒加载
<script setup>
import { defineAsyncComponent } from 'vue'

const HeavyChart = defineAsyncComponent(() =>
  import('./components/HeavyChart.vue')
)
</script>

// 3. 骨架屏
<template>
  <Suspense>
    <template #default>
      <AsyncComponent />
    </template>
    <template #fallback>
      <SkeletonScreen />
    </template>
  </Suspense>
</template>

// 4. 代码分割（Vite）
// vite.config.js
export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          'echarts': ['echarts'],
          'vendor': ['vue', 'pinia']
        }
      }
    }
  }
}

// 5. 图片懒加载
import { useIntersectionObserver } from '@vueuse/core'

const imgRef = ref()
const { stop } = useIntersectionObserver(
  imgRef,
  ([{ isIntersecting }]) => {
    if (isIntersecting) {
      // 加载图片
      imgRef.value.src = realSrc
      stop()
    }
  }
)

性能检测清单

使用 Lighthouse 分析性能指标
Chrome DevTools Performance 录制加载过程
检查 Network 面板的资源加载时间
使用 Vue DevTools 查看组件渲染时间
监控 Memory 面板的内存占用趋势
检查 Console 警告和错误

最佳实践

大数据列表：虚拟滚动 + shallowRef
频繁更新：防抖节流 + v-memo
图表组件：缓存实例 + 按需更新
首屏加载：路由懒加载 + 骨架屏 + 代码分割
内存管理：及时清理定时器、事件、第三方实例
监控优化：使用性能监控工具持续优化

扩展阅读

2.Vue 组件通信 - 标准答案

Wed, 21 Jan 2026 07:16:00 GMT

题目

考察点：方案选型、状态管理、性能优化、架构设计

场景描述：
一个电商后台管理系统，包含：

多层级的嵌套路由（3-5层）
全局状态（用户信息、权限、主题配置）
跨模块的数据共享（订单模块 ↔ 库存模块 ↔ 财务模块）
实时数据更新（WebSocket 推送的订单状态变更）

问题：

方案选型：props/emit、provide/inject、Vuex、Pinia、EventBus 这些方案，您会如何组合使用？
状态管理：Vuex vs Pinia，在 Vue3 项目中您会选择哪个？为什么？
性能优化：当状态树很大时，如何避免不必要的组件重渲染？
实战经验：您在项目中遇到过哪些组件通信的难题？

标准答案

1. 方案选型与组合使用

方案	适用场景	优点	缺点
props/emit	父子组件直接通信	简单直接、类型安全	层级多时繁琐
provide/inject	跨层级传递配置、依赖	无需逐层传递	不适合响应式数据
Pinia	全局状态、跨组件共享	组合式API、TS支持好	学习成本
EventBus	跨组件事件通信	灵活	难以维护、Vue3已移除

推荐组合方案：

// 1. 父子组件：props/emit
<ChildComponent :data="parentData" @update="handleUpdate" />

// 2. 跨层级配置：provide/inject
// 父组件
provide('theme', computed(() => theme.value))

// 子孙组件
const theme = inject('theme')

// 3. 全局状态：Pinia
import { defineStore } from 'pinia'

export const useUserStore = defineStore('user', () => {
  const user = ref(null)
  const isLoggedIn = computed(() => !!user.value)
  
  function login(credentials) {
    // ...
  }
  
  return { user, isLoggedIn, login }
})

// 4. 实时更新：Pinia + WebSocket
export const useOrderStore = defineStore('order', () => {
  const orders = ref([])
  
  onMounted(() => {
    const ws = new WebSocket('ws://...')
    ws.onmessage = (event) => {
      const order = JSON.parse(event.data)
      updateOrder(order)
    }
  })
  
  return { orders }
})

2. Vuex vs Pinia

选择 Pinia 的理由：

更好的 TypeScript 支持

// Pinia - 自动类型推导
export const useStore = defineStore('main', () => {
  const count = ref(0)
  const doubleCount = computed(() => count.value * 2)
  function increment() {
    count.value++
  }
  return { count, doubleCount, increment }
})

// 使用时有完整类型提示
const store = useStore()
store.count  // number
store.doubleCount  // number
store.increment()  // void

组合式 API 风格（更符合 Vue3）
无需 mutations（简化代码）
支持多实例（适合SSR和多标签页场景）
更轻量（~1KB）

核心差异：

特性	Vuex	Pinia
API 风格	Options API	Composition API
Mutations	必需	无需（直接修改state）
TypeScript	需手动声明	自动推导
DevTools	支持	支持
模块化	需配置 modules	天然支持多 store
SSR	支持	更好的支持

3. 性能优化

避免不必要的重渲染：

// 1. 使用 storeToRefs 解构响应式属性
import { storeToRefs } from 'pinia'

const store = useStore()
const { count, doubleCount } = storeToRefs(store)  // 保持响应式
const { increment } = store  // 方法不需要响应式

// 2. 选择性订阅（只监听需要的状态）
const orderStore = useOrderStore()

// ❌ 不好：订阅整个store
watch(() => orderStore.$state, () => {
  // 任何状态变化都会触发
})

// ✅ 好：只监听特定状态
watch(() => orderStore.orders, (newOrders) => {
  // 只在orders变化时触发
})

// 3. 使用计算属性过滤数据
const filteredOrders = computed(() => {
  return orderStore.orders.filter(order => order.status === 'pending')
})

// 4. 虚拟滚动处理大列表
import { useVirtualList } from '@vueuse/core'

const { list, containerProps, wrapperProps } = useVirtualList(
  largeList,
  { itemHeight: 50 }
)

4. 实战经验

常见问题与解决方案：

问题1：多标签页状态隔离

// 解决方案：多实例 Pinia
import { createPinia, setActivePinia } from 'pinia'

// 每个标签页创建独立的 pinia 实例
const pinia = createPinia()
setActivePinia(pinia)

app.use(pinia)

问题2：跨模块数据同步

// 订单store监听库存store变化
export const useOrderStore = defineStore('order', () => {
  const inventoryStore = useInventoryStore()
  
  watch(() => inventoryStore.stock, (newStock) => {
    // 库存变化时更新订单状态
    updateOrdersAvailability(newStock)
  })
  
  return { orders }
})

问题3：组件卸载后状态清理

export const useFormStore = defineStore('form', () => {
  const formData = ref({})
  
  function reset() {
    formData.value = {}
  }
  
  // 组件卸载时自动清理
  onUnmounted(() => {
    reset()
  })
  
  return { formData, reset }
})

最佳实践

优先使用 props/emit（父子组件）
Pinia 管理全局状态（用户、权限、主题）
provide/inject 传递依赖（配置、服务实例）
避免 EventBus（难以维护，Vue3已移除）
状态持久化：使用 pinia-plugin-persistedstate
状态分模块：按业务领域拆分 store
性能优化：使用 storeToRefs、计算属性、虚拟滚动

扩展阅读

1.Vue 响应式原理 - 标准答案

Wed, 21 Jan 2026 06:53:18 GMT

题目

考察点：底层原理理解、技术对比、边界场景、实战经验

问题：
Vue2 使用 Object.defineProperty 而 Vue3 改用 Proxy 来实现响应式系统。请从以下几个方面深入对比：

技术实现层面：两者在拦截数据变化时的核心差异是什么？
边界场景问题：Vue2 响应式系统有哪些已知的局限性？Vue3 的 Proxy 如何解决这些问题？
性能考量：在大型应用中，这两种方案的性能表现有什么差异？
实战经验：您在项目中是否遇到过 Vue2 响应式的坑？如何解决的？

标准答案

1. 技术实现层面的核心差异

Vue2 - Object.defineProperty

// Vue2 响应式实现原理
function defineReactive(obj, key, val) {
  const dep = new Dep() // 依赖收集器
  
  Object.defineProperty(obj, key, {
    enumerable: true,
    configurable: true,
    get() {
      // 依赖收集
      if (Dep.target) {
        dep.depend()
      }
      return val
    },
    set(newVal) {
      if (newVal === val) return
      val = newVal
      // 通知更新
      dep.notify()
    }
  })
}

// 递归遍历对象的所有属性
function observe(obj) {
  if (typeof obj !== 'object' || obj === null) return
  
  Object.keys(obj).forEach(key => {
    defineReactive(obj, key, obj[key])
    // 递归处理嵌套对象
    if (typeof obj[key] === 'object') {
      observe(obj[key])
    }
  })
}

特点：

✅ 可以精确拦截对象属性的读写
❌ 只能拦截已存在的属性
❌ 必须遍历对象的每个属性
❌ 无法监听属性的新增/删除
❌ 无法监听数组索引和 length

Vue3 - Proxy

// Vue3 响应式实现原理
function reactive(target) {
  return new Proxy(target, {
    get(target, key, receiver) {
      const result = Reflect.get(target, key, receiver)
      
      // 依赖收集
      track(target, key)
      
      // 惰性代理：只在访问时才代理嵌套对象
      if (typeof result === 'object' && result !== null) {
        return reactive(result)
      }
      
      return result
    },
    
    set(target, key, value, receiver) {
      const oldValue = target[key]
      const result = Reflect.set(target, key, value, receiver)
      
      // 触发更新
      if (oldValue !== value) {
        trigger(target, key)
      }
      
      return result
    },
    
    deleteProperty(target, key) {
      const hadKey = Object.prototype.hasOwnProperty.call(target, key)
      const result = Reflect.deleteProperty(target, key)
      
      if (hadKey && result) {
        trigger(target, key)
      }
      
      return result
    }
  })
}

特点：

✅ 可以拦截对象本身的 13 种操作（get、set、deleteProperty、has、ownKeys等）
✅ 可以监听属性的新增/删除
✅ 可以监听数组索引和 length
✅ 惰性代理：只在访问嵌套对象时才代理
✅ 使用 Reflect 确保正确的 this 绑定

核心差异总结：

特性	Object.defineProperty	Proxy
拦截层级	属性级别	对象级别
新增属性	❌ 无法监听	✅ 自动监听
删除属性	❌ 无法监听	✅ 自动监听
数组索引	❌ 无法监听	✅ 自动监听
初始化	必须递归遍历	惰性代理
性能	初始化慢	访问时略慢

2. 边界场景问题与解决方案

Vue2 的局限性

问题1：无法监听属性新增

// Vue2 - 无法响应
const vm = new Vue({
  data: {
    user: {
      name: 'Alice'
    }
  }
})

// ❌ 直接添加属性，视图不会更新
vm.user.age = 18

// ✅ 必须使用 $set
vm.$set(vm.user, 'age', 18)
// 或
Vue.set(vm.user, 'age', 18)

问题2：无法监听属性删除

// Vue2 - 无法响应
delete vm.user.name  // ❌ 视图不会更新

// ✅ 必须使用 $delete
vm.$delete(vm.user, 'name')

问题3：无法监听数组索引变化

// Vue2 - 无法响应
const vm = new Vue({
  data: {
    items: ['a', 'b', 'c']
  }
})

vm.items[0] = 'x'  // ❌ 视图不会更新
vm.items.length = 0  // ❌ 视图不会更新

// ✅ 必须使用数组方法或 $set
vm.$set(vm.items, 0, 'x')
vm.items.splice(0, vm.items.length)

Vue2 的变通方案：

重写了 7 个数组方法（push、pop、shift、unshift、splice、sort、reverse）
提供 $set 和 $delete API

Vue3 的解决方案

// Vue3 - 全部自动响应
import { reactive } from 'vue'

const state = reactive({
  user: {
    name: 'Alice'
  },
  items: ['a', 'b', 'c']
})

// ✅ 属性新增 - 自动响应
state.user.age = 18

// ✅ 属性删除 - 自动响应
delete state.user.name

// ✅ 数组索引 - 自动响应
state.items[0] = 'x'

// ✅ 数组长度 - 自动响应
state.items.length = 0

// ✅ Map/Set - 也支持响应式
const map = reactive(new Map())
map.set('key', 'value')  // 自动响应

3. 性能考量

初始化性能

Vue2：必须递归遍历所有属性

// Vue2 - 初始化时递归遍历
function observe(obj) {
  if (typeof obj !== 'object') return
  
  // 遍历所有属性
  Object.keys(obj).forEach(key => {
    defineReactive(obj, key, obj[key])
    // 递归处理嵌套对象
    observe(obj[key])
  })
}

const data = {
  level1: {
    level2: {
      level3: {
        level4: { /* 1000个属性 */ }
      }
    }
  }
}

// 初始化时会遍历所有嵌套对象的所有属性
observe(data)  // 慢！

Vue3：惰性代理

// Vue3 - 只在访问时才代理嵌套对象
function reactive(target) {
  return new Proxy(target, {
    get(target, key) {
      const result = Reflect.get(target, key)
      
      // 只在实际访问时才代理嵌套对象
      if (typeof result === 'object' && result !== null) {
        return reactive(result)
      }
      
      return result
    }
  })
}

const data = reactive({
  level1: {
    level2: {
      level3: {
        level4: { /* 1000个属性 */ }
      }
    }
  }
})

// 初始化很快，只代理了最外层对象
// 只有访问 data.level1 时才代理 level1

性能对比：

初始化性能：Vue3 > Vue2（惰性代理 vs 递归遍历）
运行时性能：Vue2 ≈ Vue3（Proxy 单次操作略慢，但差异很小）
内存占用：Vue3 < Vue2（惰性代理减少了不必要的代理对象）

大型应用优化建议

Vue2 优化：

// 使用 Object.freeze 跳过响应式
export default {
  data() {
    return {
      // 大量静态数据，不需要响应式
      staticData: Object.freeze(largeArray),
      // 需要响应式的数据
      dynamicData: []
    }
  }
}

Vue3 优化：

import { shallowReactive, shallowRef, markRaw } from 'vue'

// 浅层响应式：只代理第一层
const state = shallowReactive({
  nested: { /* 深层对象，不会被代理 */ }
})

// 浅层 ref：不深度监听 .value 的变化
const list = shallowRef([/* 大数组 */])

// 标记为非响应式
const data = markRaw({
  /* 永远不会变成响应式 */
})

4. 实战经验与常见坑

坑1：Vue2 动态添加属性不响应

问题场景：

export default {
  data() {
    return {
      form: {
        name: ''
      }
    }
  },
  mounted() {
    // ❌ 后端返回的额外字段，视图不更新
    this.$http.get('/api/form').then(res => {
      this.form.email = res.email  // 不响应！
    })
  }
}

解决方案：

// 方案1：使用 $set
this.$set(this.form, 'email', res.email)

// 方案2：整体替换对象
this.form = { ...this.form, email: res.email }

// 方案3：初始化时声明所有字段
data() {
  return {
    form: {
      name: '',
      email: ''  // 提前声明
    }
  }
}

坑2：数组索引修改不响应

问题场景：

export default {
  data() {
    return {
      list: [{ id: 1, name: 'A' }, { id: 2, name: 'B' }]
    }
  },
  methods: {
    updateItem() {
      // ❌ 不响应
      this.list[0] = { id: 1, name: 'Updated' }
    }
  }
}

解决方案：

// 方案1：使用 $set
this.$set(this.list, 0, { id: 1, name: 'Updated' })

// 方案2：使用 splice
this.list.splice(0, 1, { id: 1, name: 'Updated' })

// 方案3：使用 Vue.set
Vue.set(this.list, 0, { id: 1, name: 'Updated' })

坑3：嵌套对象响应式丢失

问题场景：

// Vue2
export default {
  data() {
    return {
      user: {
        profile: {
          name: 'Alice'
        }
      }
    }
  },
  methods: {
    resetProfile() {
      // ❌ 新对象没有响应式
      this.user.profile = { name: 'Bob', age: 20 }
      // age 字段不响应
    }
  }
}

解决方案：

// 方案1：使用 $set 添加新属性
this.$set(this.user.profile, 'age', 20)

// 方案2：使用扩展运算符
this.user = {
  ...this.user,
  profile: { name: 'Bob', age: 20 }
}

// 方案3：Vue3 没有这个问题
const user = reactive({ profile: { name: 'Alice' } })
user.profile = { name: 'Bob', age: 20 }  // ✅ 自动响应

最佳实践

Vue2 项目

提前声明所有属性：避免动态添加属性
使用 $set/$delete：处理动态属性
数组操作用变异方法：push、splice 等
大数据用 Object.freeze：性能优化

Vue3 项目

选择合适的响应式 API：
- reactive()：对象/数组
- ref()：基本类型
- shallowReactive()：浅层响应式
- readonly()：只读代理
性能优化：
- 使用 shallowRef/shallowReactive 处理大数据
- 使用 markRaw 标记非响应式数据
- 使用 toRaw 获取原始对象
注意事项：
- reactive 对象解构会丢失响应式，使用 toRefs
- ref 在模板中自动解包，在 JS 中需要 .value

扩展阅读

高级前端开发面试题目清单

Wed, 21 Jan 2026 06:39:25 GMT

面试岗位：高级前端开发（偏Node全栈）
题目总数：10题
预计时长：30-40分钟
创建日期：2026-01-21

题目分布

技术方向	题目数量	题号
Vue2/Vue3 技术深度	6题	1-6
Node.js 技术	2题	7-8
架构设计	1题	9
团队管理	1题	10

Vue2/Vue3 技术部分（6题）

第1题：Vue 响应式原理

考察点：底层原理理解、技术对比、边界场景、实战经验

问题：
Vue2 使用 Object.defineProperty 而 Vue3 改用 Proxy 来实现响应式系统。请从以下几个方面深入对比：

技术实现层面：两者在拦截数据变化时的核心差异是什么？
边界场景问题：Vue2 响应式系统有哪些已知的局限性？Vue3 的 Proxy 如何解决这些问题？
性能考量：在大型应用中，这两种方案的性能表现有什么差异？
实战经验：您在项目中是否遇到过 Vue2 响应式的坑？如何解决的？

第2题：Vue 组件通信

考察点：方案选型、状态管理、性能优化、架构设计

场景描述：
一个电商后台管理系统，包含：

多层级的嵌套路由（3-5层）
全局状态（用户信息、权限、主题配置）
跨模块的数据共享（订单模块 ↔ 库存模块 ↔ 财务模块）
实时数据更新（WebSocket 推送的订单状态变更）

问题：

方案选型：props/emit、provide/inject、Vuex、Pinia、EventBus 这些方案，您会如何组合使用？各自适用的场景是什么？
状态管理：Vuex vs Pinia，在 Vue3 项目中您会选择哪个？为什么？它们的核心差异是什么？
性能优化：当状态树很大时（如商品列表有上千条数据），如何避免不必要的组件重渲染？
实战经验：您在项目中遇到过哪些组件通信的难题？如何解决的？

第3题：Vue3 性能优化

考察点：性能调优、内存管理、渲染优化、实战能力

场景描述：
您负责优化一个 Vue3 的数据可视化大屏项目，存在以下性能问题：

现状：

实时展示 5000+ 条 设备状态数据（每秒通过 WebSocket 更新 50-100 条）
页面包含多个图表组件（ECharts）、表格、卡片
首屏加载时间 8秒+，滚动时有明显卡顿
内存占用持续增长，1小时后页面变得很慢

问题：

渲染优化：除了虚拟滚动，Vue3 还有哪些优化大数据列表渲染的手段？（如 computed、watchEffect、shallowRef、shallowReactive 等）
组件优化：如何优化频繁更新的图表组件？考虑防抖节流、组件缓存等
内存泄漏：如何排查并解决 Vue3 应用中的内存泄漏问题？常见的泄漏点有哪些？
首屏优化：针对 8秒+ 的首屏时间，有哪些具体的优化方案？

第4题：Vue2 迁移到 Vue3

考察点：迁移策略、技术重构、风险控制、项目管理

场景描述：
您的团队需要将一个运行了 3 年的 Vue2 项目（10万+ 行代码）迁移到 Vue3。

项目现状：

大量使用 Mixins 实现逻辑复用
依赖 Vue2 生态（Element UI、vue-router 3.x、Vuex 3.x）
使用了一些 Vue2 特有的 API（$listeners、$scopedSlots、filters）
部分第三方库可能不兼容 Vue3

问题：

迁移策略：一次性全量迁移 vs 渐进式迁移？您会选择哪种方案？如何规划迁移路径？
Composition API 重构：如何将 Options API（尤其是 Mixins）重构为 Composition API？有哪些最佳实践？
生态适配：Element UI → Element Plus，Vuex → Pinia 等生态迁移的注意事项？
风险控制：如何保证迁移过程中业务不受影响？如何做回归测试？
实战经验：您是否有过类似的迁移经验？遇到过哪些坑？

第5题：Vue Diff 算法

考察点：源码理解、算法原理、性能优化

问题：
Vue 的虚拟 DOM diff 算法是其性能优化的核心。

双端对比算法：Vue2 使用的双端对比（double-ended comparison）算法是如何工作的？为什么比简单的从头到尾对比更高效？
Vue3 优化：Vue3 在 diff 算法上做了哪些优化？（如最长递增子序列、静态提升、patchFlag 等）
与 React 对比：Vue 的 diff 算法与 React 的 diff 算法有什么本质区别？各有什么优劣？
Key 的作用：为什么 v-for 必须要加 key？使用 index 作为 key 有什么问题？能举个实际的例子吗？
实战应用：在实际开发中，如何利用对 diff 算法的理解来优化列表渲染性能？

第6题：Nuxt.js SSR 实战

考察点：SSR/SSG理解、数据获取、性能优化、实战经验

场景描述：
您的团队使用 Nuxt.js（Vue3 版本）开发了一个内容型网站（博客/新闻类），需要考虑 SEO 和首屏性能。

场景：

文章详情页需要服务端渲染（SEO）
首页需要加载大量文章列表和推荐内容
部分交互组件（评论、点赞）需要客户端渲染

问题：

SSR vs SSG vs CSR：在 Nuxt.js 中，这三种渲染模式分别适用于什么场景？如何混合使用？
数据获取：asyncData、fetch、useFetch、useAsyncData 这些 API 的区别是什么？什么时候用哪个？
性能优化：Nuxt.js 项目中常见的性能瓶颈有哪些？如何优化服务端渲染的性能？
实战问题：
- 如何处理服务端和客户端环境差异（如 window、localStorage 不可用）？
- 如何避免服务端渲染的内存泄漏？
- 您遇到过哪些 Nuxt.js 的坑？
项目经验：您是否有 SSR/SSG 的实际项目经验？效果如何？

Node.js 技术部分（2题）

第7题：Node.js Event Loop

考察点：事件循环理解、微任务/宏任务、实战应用

场景代码：

console.log('1');

setTimeout(() => {
  console.log('2');
  Promise.resolve().then(() => console.log('3'));
}, 0);

Promise.resolve().then(() => {
  console.log('4');
});

process.nextTick(() => {
  console.log('5');
});

console.log('6');

问题：

执行顺序：上述代码的输出顺序是什么？简要说明原因。
核心概念：process.nextTick、Promise.then、setTimeout 的执行优先级是怎样的？
实战应用：在实际 Node.js 项目中（如数据库批量操作、文件读写），您如何利用事件循环的理解来优化性能？

第8题：Node.js 性能调优

考察点：内存管理、性能诊断、CPU优化、实战能力

场景描述：
您负责维护一个 Node.js API 服务，生产环境出现以下问题：

现象：

服务运行一段时间后响应变慢
内存占用持续增长，最终导致 OOM（Out of Memory）
CPU 偶尔飙升到 100%

问题：

内存泄漏排查：如何定位和排查 Node.js 应用的内存泄漏？有哪些常用的工具和方法？（如 heapdump、Chrome DevTools、process.memoryUsage() 等）
常见泄漏点：Node.js 中常见的内存泄漏场景有哪些？（如全局变量、闭包、事件监听器、定时器等）
CPU 密集任务：如果需要在 Node.js 中处理 CPU 密集型任务（如图片处理、大数据计算），有哪些优化方案？（如 Worker Threads、子进程、任务队列等）
实战经验：您在项目中遇到过类似的性能问题吗？如何解决的？

架构设计部分（1题）

第9题：微前端架构设计

考察点：架构能力、技术选型、问题解决

场景描述：
您的公司有多个前端团队，分别负责不同的业务模块（订单、库存、财务、用户中心），技术栈混杂（Vue2、Vue3、React）。现在需要将这些模块整合到一个统一的后台管理系统中。

需求：

各模块独立开发、独立部署
支持 Vue2、Vue3 混合运行
共享公共依赖（如 Vue、Element UI）以减小包体积
主应用负责路由、权限、布局

问题：

技术方案：微前端的实现方案有哪些？（如 qiankun、Micro-App、Module Federation、iframe）您会选择哪个？为什么？
核心挑战：微前端架构的核心技术难点是什么？（如 JS 沙箱隔离、样式隔离、应用间通信）如何解决？
实战考量：Vue2 和 Vue3 共存时有什么注意事项？如何避免版本冲突？

团队管理部分（1题）

第10题：团队管理与技术债务

考察点：管理能力、技术推动、团队协作

场景描述：
作为高级前端开发/技术负责人，您不仅要写代码，还要带团队、推动项目。

场景：
您接手一个老项目，代码质量堪忧：

没有代码规范，每个人的代码风格完全不同
没有单元测试，改代码如履薄冰
技术栈老旧（Vue2 + Webpack4），但业务压力大，没时间重构
团队成员水平参差不齐，Code Review 流于形式

问题：

技术债务平衡：业务需求紧急 vs 技术重构，如何平衡？您会采取什么策略？
团队规范落地：如何推动代码规范、ESLint、Prettier、Git Commit 规范在团队中落地？（而不是仅仅写个文档）
Code Review 文化：如何让 Code Review 真正发挥作用，而不是走形式？
实战经验：分享一个您在团队管理或技术推动中遇到的难题，以及您的解决方案。

评分标准

每题满分 10分，总分 100分

分数段	评级	标准
10-9分	优秀	深度理解原理 + 丰富实战经验 + 有独特见解
8-7分	良好	理解原理 + 有实战经验 + 回答完整
6-5分	及格	基本理解 + 有一定经验 + 回答尚可
4-3分	不及格	理解片面 + 经验不足 + 回答欠缺
2-1分	差	不理解原理 + 无实战经验
0分	跳过/无回答	候选人跳过此题或无法回答

总体评级参考

总分范围	评级	建议
90-100分	A+	优秀，强烈推荐录用
80-89分	A	良好，推荐录用
70-79分	B+	合格，可以录用
60-69分	B	基本合格，需权衡
50-59分	C	不太合格，不建议录用
<50分	D	不合格，不建议录用

注意事项

面试官须知

允许候选人跳过不熟悉的题目
鼓励候选人结合实战经验回答
适度追问，但不要过度刁难
客观评分，避免主观偏见

候选人须知

可以跳过不熟悉的题目，不影响整体评价
尽量用实际项目案例说明
不懂的直接说不懂，不要瞎编
思路清晰比知识全面更重要

本面试题目清单配套文档：

01-interview-prompt-template.md - 面试提示词模板
02-interview-questions.md - 本文档
03-interview-standard-answers.md - 标准答案参考
04-interview-assessment-report.md - 候选人评估报告

20分钟重构5000行代码：AI让编程成本趋近于零

Tue, 20 Jan 2026 00:18:44 GMT

最近几天感受到SKILL带来的便利之后，发现其核心能力除了本身渐进式披露的特性之外，scripts 部分可以大大拓展其能力边界，使其产出稳定可靠的产物。

虽然很多大佬提供了很多优秀的 SKILL 可以直接用，但是他们的 SKILL 也是AI构建的，公布的成品仅仅是AI对他们脑子里想法的实现，一旦他们的工作流发生变化，SKILL也会跟着发生变化。

所以你要么和别人步伐完全一致，要么就要自建自己的SKILL、脚本。

而且不要觉得重建自己的工具是多么麻烦的一件事，不管是谁，都是用AI编写的。不会编程的，用自然语言也能写好SKILL。会编程的，用AI写出的脚本会更贴合自己的需求，并且可以随着自己工作流的进化而逐渐丰富。

做什么东西都考虑成本的思维在这个时代真的需要转换一下，写工具已经近乎没有成本了。现在是需要把自己脑子里的东西倾泻，然后落地。

以我重构@zzclub/z-cli项目为例，分享一下最近使用opencode时的一些感受。

永远先Plan再Build

在使用vscode里的Github Copilot时，它已经有了Plan模式，但它明显不是一个真实的Plan模式，仅仅是把Agent的编辑能力给禁用了，Agent在得到指令后会马上想去执行，而不是真的给我做计划，然后发现自己不能编辑，再回头把自己要写的东西先输出给我。多少有点鸡肋。

如果直接Build，经常会出现它做了你意料之外的工作，然后你不得不再补充一句：我不是让你xxx，你怎么xxx，给我xxx

所以只有先让Agent输出它的Plan，你才能提前发现它的错误，从而避免一轮又一轮的纠错。

但这就对非开发者有点影响，因为Plan通常比较详细，如果你看不懂代码，仅靠文字描述，很有可能没能发现AI已经“走错了路”

所以，作为全栈开发者，又能非常清晰的输出自己的架构，在Plan阶段就可以纠正绝大部分错误。

另外，架构并不是指细节到代码里的每个类负责什么都告诉AI，AI本身的编码能力就强于高级开发，只需要从更高的维度用自然语言表述自己的意图即可。

只要不是简单的一句我想要什么什么，而是把自己的产品/脚本语言、背景、用途、使用场景交待清楚，相信顶级的大模型都能输出一个优秀的技术架构。

我的老项目基于JavaScript，包含 chalk、commander、inquirer、ora、shelljs这些依赖包。是一个之前服务于公司内部项目的一些小工具，功能包括：i18n、翻译api、图片压缩等。

首先我让AI分析项目，输出包含全部功能的文档到docs目录下，方便后续它根据此文档来重构。

然后明确要求AI使用 Bun+TypeScript 重构，核心依赖包改为 consola，并附上GitHub地址让AI去读文档。

再结合新技术栈和功能文档，以及此项目要达成的什么效果，比如兼容目前的什么主流应用、自己的独立应用，支持用户使用npx直接调用等等，输出一份重构文档。

重构文档包含了所有它完整的架构方案、目录结构以及一些代码实例，**此时就可以仔细审查，然后指出它的错误，直到整个文档都没问题。**这一步你指不出错误，就不要怪后面它再出错了。

确认无误后切换到Build模式，开始工作

这次长任务一共修改了45个文件，近5000行代码，中间经过了它自己的自动测试和纠错。在完成后，我没有发现任何错误。

从Plan到Build，用时不到20分钟。

完成后我可以生成一个 compress-image SKILL，里面明确指定调用 z tiny -f {目标文件或目录} -r --output {输出目录} 来完成图片压缩任务。

z 是此 cli 的别名

这个CLI工具既可以单独使用，也可以让SKILL明确调用，并且它一定完全适合自己。如果有其他应用想调用，自己也可以很方便的对接。

用别人用AI写的SKILL就会陷入：AI读AI写的，AI再自己对接上个AI写的，中间只有你啥都不知道。

别人可能是用各种方式（各种脚本语言）实现的SKILL，并不一定适合你，并且一旦改动，也不可能要求作者单独再教你。

所以还是尽早学着创建自己的SKILL吧。

能力强的人用AI更强

Mon, 19 Jan 2026 13:50:00 GMT

最近 Anthropic 发布了第四期 Economic Index 报告，基于 200 万次 Claude 对话数据（100 万来自 Claude.ai，100 万来自 API），引入了"经济原语"这个新的分析框架。

这次报告给出了一个和大众认知相反的结论。

很多人以为 AI 会先从流水线和客服这些简单工作开始替代，知识工作者暂时还安全。

但真实情况是：理解提示词所需的教育水平越高，AI 带来的任务时长缩减就越明显。

换句话说，AI 正在从知识工作的核心地带切入，而不是从边缘蚕食。

复杂任务，反而跑得更快

官方数据显示了一个反直觉的现象：

任务越复杂，AI 带来的提速效果越明显。

即使考虑到复杂任务的成功率更低这个因素，这个结论依然成立。

具体来说，需要更高教育水平才能理解的任务，AI 能节省的时间反而更多。但复杂任务的成功率确实更低一些，说明了一件事：AI 在高难度任务上的表现更不稳定。

你用 AI 帮你写代码、做分析、起草方案，每次都像在抛硬币——这次能不能靠谱完成，谁也不知道。

会问的人，得到更多

报告发现了一个有趣的现象：用户输入的表达水平和 AI 回复的表达水平，呈现高度相关性。

说人话就是：你用什么水平的语言问问题，AI 就用什么水平的语言回答你。

这不是 AI 在刻意迁就你，而是它的训练方式决定的。Claude 会自动匹配用户的表达层次。

所以，原本架构能力更强的开发者，用同样的 AI，效率反而更高。

为什么？

因为架构能力很大程度上受制于表达能力——包括语言和文字上的表达。

以前这种能力体现在和团队的沟通上，谁能把需求说清楚、把方案讲明白，谁就能推动项目往前走。

现在这种能力同样体现在和 AI 的沟通上。你能不能写出高质量的 Prompt，能不能把复杂问题拆解成 AI 能理解的小步骤，直接决定了 AI 能给你多大的帮助。

但这并不意味着非技术背景的人就没机会了。

事实上，很多没有编程背景的人，通过 AI 已经做出了不少有用的 App、工具、甚至小产品。

关键在于：你能不能清晰地表达你想要什么。

不一定要懂算法、懂数据结构，但你得能把你的需求、你的逻辑、你的期望，用准确的语言描述出来。

这种能力以前可能叫"产品思维"，现在可以叫"Prompt 工程"，但本质上都是同一件事：把脑子里模糊的想法，翻译成可执行的指令。

多轮对话才是关键

官方数据揭示了另一个现象：

Claude.ai（网页端）和 API 调用的成功率差异明显，前者显著高于后者。

差在哪？

多轮对话。

网页端用户可以纠错、引导、迭代。AI 给的第一版不满意，你可以追问、可以补充细节、可以调整方向。

而 API 调用通常是"一锤子买卖"，提交请求就等结果，没有纠错机会。

API 调用的数据显示，Claude 在约 3.5 小时的任务上能达到 50% 成功率。但在 Claude.ai 上，即使是更长时间的任务，成功率依然保持在较高水平。

原因就是多轮对话把复杂任务分解成了小步骤，每一轮都有机会纠偏。

人类的引导能力，仍然是关键变量。

这也解释了为什么架构能力强的开发者用 AI 更高效：他们知道怎么把大问题拆成小问题，知道每一步应该问什么、验证什么。

白领工作正在被"掏空"

官方报告提到了一个"去技能化"(deskilling) 的效应：

因为 Claude 倾向于覆盖那些需要更高技能水平的任务，如果这些任务被自动化，员工可能会被留下更多常规性工作。

当然，报告也提醒说，这个假设建立在"自动化会缩减工作的这些方面"的前提上，实际上工作可能会以其他方式演变。

但如果顺着这个逻辑想，会发生什么？

技术写作员：AI 接管了分析、审稿、内容生成这些核心工作，人类可能只剩下画图和排版。

旅行代理：AI 做行程规划、比价、推荐，人类只剩打票收款。以前需要丰富经验才能做好的工作，现在变成了简单的执行角色。

教师：AI 能帮忙批改作业、做研究、准备教案，这些恰恰是教师工作中最需要专业知识的部分。剩下的主要是课堂管理和面对面互动。

问题不在于失业，而在于工作内容的降级。

你可能仍然有工作，但做的事情变得更琐碎、更机械。

当然也有例外。

比如房产经理：AI 接管了记账、文档管理这些低端任务，人类可以专注于合同谈判和客户关系，工作内容反而更有价值。

关键在于：AI 接管的是不是你工作中最核心的那部分？

写在最后

这份报告最重要的发现，不是 AI 能做什么，而是谁能更好地用 AI。

能力强的人，用 AI 之后更强。

会表达的人，从 AI 那里得到更多。

AI 时代不光是淘汰，更多的是机会。

但前提是：你得能说清楚你想要什么。

没用的旧代码不要丢，放到SKILL里继续用

Thu, 15 Jan 2026 19:31:33 GMT

前言

没用的旧代码不要丢，也不要放在转转上回收😄

放到SKILL里当做一个脚本来用说不定会更合适。

SKILL

SKILL是AI编程助手（如OpenCode）中的一种可复用工作流机制。它诞生的背景是：传统的Prompt工程中，开发者需要反复编写相似的指令和上下文说明，既低效又容易遗漏细节。SKILL将"意图描述 + 详细要求 + 工具脚本"打包成一个可被AGENT智能识别和调用的单元，让过往积累的代码、脚本和工作流程得以在AI时代继续发挥价值。

SKILL从前端的概念上来理解，类似于一个composable。

它可以是一段写好的Prompt，也可以有单个脚本（函数），也可以是多个脚本，所以比单纯的函数复用要更灵活和多变一些。

那它和MCP（MCP只是协议，但下文MCP同时指代背后的服务）有什么区别呢

MCP就类似于一张「入场券」，仅仅是提供给Agent调用此服务的接口。

在调用MCP时，往往需要你先写一段Prompt，交待背景、角色、要做什么，然后AGENT再去调用MCP，拿到结果，按你说的要求整理和执行下一步动作。

SKILL好就好在，它可以记住你这一套操作，是真正的复用。

在执行一项任务前，你的意图就是这个SKILL的description。你的要求就是它的SKILL.md。你的MCP，也就是那个输出结果明确的服务或脚本，同样可以用在SKILL/scripts里。

所以，以前对自己有用的服务、脚本，到今天依然可用。仅仅是换了一种调用方式

职能细化

在 opencode/claudecode 中SKILL的调用方式，类比传统的服务/古法编程，从明确的函数调用、接口请求，变成了AGENT语义理解并调用SKILL。

传统：后端提供接口 => https://api.example.com/get/xxx

SKILLS: SKILL/description

当给AGENT/Primary阐述我们的要求时，它会理解和规划你的要求，并且查看SKILLS里的description是否在你的要求内，如果有SKILL符合，则使用SKILL来完成。

所以Description就是给AGENT的接口文档

此时SKILL里的SKILL.md刚刚被加载到上下文，它就会开始执行这个SKILL里的任务，所以你在这个SKILL.md才是你最详细的要求，以及完成后要做什么。而不是一开始就发一大段Prompt，发现有问题之后，再说你哪里哪里理解的不对，是这样那样。

多个SKILL之间可以在其内部的任务要求中达到串联协作，或者通过一个SKILL把其他SKILL串联。注意，串联的前提是AGENT能够从你的任务描述中理解应该使用哪个具体的SKILL。。

在Vscode中用Github Copilot编程时，大模型经常会犯一些无语的错误。

比如，总是要生成文档。写个东西，二话不说文档先写一长串，或者是做完用文档总结一下。当然，这只是某些模型的特点。

再比如，写完代码，格式乱了、错行了，TS类型错了。这种错误经常出现。它不知道用项目自带的lint命令修复，哪怕你写到某个它默认会携带到上下文里的md文档里。因为一个窗口做的任务太多了，不知道哪次对话就把某个要求给丢了。

这些错误在我使用了opencode + ohmyopencode 之后就很少出现了。原因应该也是职能的细化，使其大模型工作效率提高了不少。工具的进化也让上下文问题优化了许多。

所以，学的慢学的晚也不是坏事了，眼一闭一睁，问题已经在源头被解决了。

能力扩展

SKILL放在代码里仅仅是提高准确性和复用率，（个人感觉）放在非编程领域可能会更好使一些。

在SKILL之前，普遍用workflow来编排自己的各种任务，（比如n8n）以达到自动化的效果。这让原本就有赚钱业务的人更加赚钱。

SKILL的能力不在workflow之下。

假如发一篇文章原本的模式是这样的：

先让A开发一个脚本、服务，完成抓取数据、处理数据等需求。然后由A把数据发给B，B负责润色文案，交给C去处理文章配图，最后交给D勘误和审核，然后再进行多平台发布。

有个AI之后，A肯定是不要了，大模型写出来的更快更好。B也不要了，AI自己润色。C也不要了，AI生图。D也不要了，AI勘误。多平台发布，以前就是聚合平台，现在还继续用。

所以只需要你一个人，把ABCD之间的调度（使用自然语言）粘合在一起。ABCD要做什么是固定的，产出也是固定的。你也不必把他们所有的工作职能都放在自己这，只需要明确：**进行到哪一步，去找谁解决。**最后再配个监理，持续敲打。

你看，非编程领域是不是可以先一步下岗了。😄

一点SKILL的小思考

🔚

Dan Koe的三级表达框架

Thu, 15 Jan 2026 17:06:05 GMT

搬运自在悉尼和稀泥@X

新手用微型故事结构（提出痛点-放大危害-给出方案）快速抓牢听众；

进阶者用金字塔原理（结论先行-论据支撑-证据落地）让表达逻辑清晰；

高阶者则用跨领域融合法（痛点引入-跨学科佐证-独创解法）打造独特表达风格。

他同时强调，写作是锻炼表达的核心途径，公开分享还能获取反馈、优化观点。

所以：想让表达更有分量？

记住这两步：先攒8-10个自己的核心观点反复打磨。再按“提痛点-给方案”“结论先行”或“跨领域融合”的框架输出。

不用逼自己说新话，把好观点讲透，就是最高级的表达。

千问整合了全阿里生态，为什么唯独少了闲鱼？

Thu, 15 Jan 2026 08:35:00 GMT

最近阿里发布了全新的千问，打通了淘宝、飞猪、高德、支付宝一系列生态服务。

你可以直接语音说"订个周末去杭州的酒店"，千问帮你搞定。想吃什么，它帮你点外卖。要去哪，它帮你规划路线叫车。

这个体验确实很丝滑。AI 助手终于从"聊天工具"变成了"超级入口"。

但我翻了一圈发现：闲鱼没在里面。

闲鱼的尴尬定位

闲鱼在阿里生态里，一直是个有点特殊的存在。

表面上看，它是个二手交易平台。但实际上呢？现在上面卖全新商品的、代购的、倒卖优惠券的，比真正卖二手的还多。

这就很微妙了。

淘宝、天猫是正价渠道，闲鱼成了"价格洼地"。同一个商品，淘宝 299，闲鱼有人 249 代付。用户用脚投票，流量往低价那边走。

千问要整合阿里生态，飞猪、高德、支付宝都好说，大家各司其职，没什么冲突。

但闲鱼不一样。它天然就和其他购物渠道存在价格竞争关系。

普通人要的是什么？

说白了，普通人用闲鱼就图一个字：便宜。

你想买个东西，打开淘宝，原价 299。然后习惯性打开闲鱼搜"XX 优惠券"，发现有人 248 包邮代付，省了 50 块。

这时候一个问题就冒出来了：AI 助手能帮我拿到这个 248 的价格吗？

如果不能，那 AI 只是帮我在淘宝下了个 299 的原价单，我还是得自己去闲鱼翻一圈。所谓的"便捷"，没解决核心需求。

更关键的是，闲鱼上那些低价，往往不在淘宝的优惠券体系里。

淘宝的券是满减券、品类券、店铺券、跨店券、直播券……一套复杂的分发机制。但闲鱼的折扣、代付、代购，是在这套体系之外的。

不管 AI 多聪明，拿不到闲鱼的价格，就不算真正理解了"我想省钱"这个意图。

谁为复杂度买单？

以前电商平台搞优惠券，设计得很复杂：凑单、定时领、蹲直播。

复杂度的背后，是"精准分发流量"、"提升用户粘性"的产品逻辑。用户要为了那几块钱优惠，多点几次、多逛几家、多停留几分钟。

现在 AI 来了，用户可以直接说"买 XX"，AI 自动下单。

那以前那套复杂度的代价，谁来承担？

平台设计了半天的凑单机制，用户根本不需要了解，AI 直接算好。定时领券、蹲直播这些，也都可以交给 AI 去做。

用户爽了，AI 变成了超级入口，但平台原本想通过"复杂度"换来的用户时长、GMV 增长，现在全被 AI 这个中间层吃掉了。

更开放还是更封闭？

千问整合阿里系 app，这是个大趋势。不光阿里，各家大厂都在做类似的事。

对用户来说，确实方便了。一句话搞定订酒店、叫车、点外卖。

但问题是：AI 会帮你比价吗？会告诉你闲鱼有更便宜的吗？

如果不会，那这个"超级入口"其实是在收窄选择。以前你至少还会主动打开闲鱼比价，现在 AI 直接帮你下单，你可能根本不知道还有更便宜的渠道。

更进一步说，如果每个生态都这么玩，阿里有千问，腾讯有腾讯元宝，字节有豆包……每个 AI 只整合自家 app，不跨平台比价。

那整个互联网生态，是更开放了，还是更封闭了？

对普通用户来说，AI 整合 app 带来的"便捷"，可能是以"价格透明度"为代价的。

你看不到更多选择，AI 也不会主动告诉你。

写在最后

从闲鱼这个案例能看出来，AI 整合 app 这件事，没那么简单。

它不只是技术问题，更是利益、定位、用户需求的博弈。

AI 会帮用户省钱，还是只是让下单更快？会打破平台壁垒，还是强化生态封闭？

这些问题，现在还没答案。

但至少，我们应该保持警惕。

便捷是好事，但如果为了便捷，放弃了比价、放弃了选择，那可能不是我们真正想要的。

你怎么看？

Milkdown神奇的Bug

Wed, 14 Jan 2026 01:41:34 GMT

🤔

在zotepad中把核心编辑器从md-editor-v3迁移成milkdown之后，体验感好了不少。

界面干干净净，md实时渲染，也不用单独预览了。

但是有一个bug我一直没解决：

如果打开新文章直接写字，在选中文本弹出milkdown的toolbar时，页面会抖动一下。应该是什么元素导致内容区域一下子变高了。

但是我尝试了很多解决办法都没法解决。

今天在体验opencode + skills 意外发现用于测试的那篇文章没抖动，当时我还在心想，真奇怪，竟然打了个新的安装包就好了？

然后我在开始写另一篇文章时，发现又产生了抖动，于是我又回到了不抖动的那篇文章，发现它还是不抖动。它俩的唯一区别就是好的文章有个H2标题，于是我给这篇文章也加了个H2标题就好了。

然后我又尝试了加入引用、分割线等，都是可以的，只要不直接写文字都可以。

神奇的bug😂

有没有知道原因的，评论区求教

opencode skills

Wed, 14 Jan 2026 00:03:39 GMT

⚠️测试文章

新增了一个 blog-publisher skill，用于在任何窗口使用 opencode 进行本地文章的发布

比较理想的流程是

写作风格确认
写文章大纲
填充内容，润色
生成配图
调用zotepad上传图片
调用zotepad发布到公众号草稿箱
调用zotepad保存文章到本地博客目录
blog-publisher发布

如果是无需确认的发布流程，比如新闻类文章，可以直接发布到博客，因为自由度较高，可以随时更改。
如果需要确认的则不能直接发到公众号平台。

小红书风格图片提示词

Mon, 12 Jan 2026 21:40:20 GMT

来自于宝玉@X

角色定义

你是一位专业的小红书视觉内容策划师，擅长将复杂内容拆解为吸引眼球的卡通风格系列信息图。

任务

请分析以下输入内容，将其拆解为 1-10 张小红书风格的系列信息图，并为每张图片输出独立的生成提示词。

拆解原则

封面图（第1张）：必须有强烈视觉冲击力，包含核心标题和吸引点
内容图（中间）：每张聚焦1个核心观点，信息密度适中
结尾图（最后1张）：总结/行动号召/金句收尾

图片数量判断标准

简单观点/单一主题：2-3 张
中等复杂度/教程类：4-6 张
深度干货/多维度分析：7-10 张

视觉风格规范（重要）

基础设定

图片类型：信息图（Infographic）
方向比例：竖版，3:4 或 9:16
整体风格：卡通风格、手绘风格

背景与配色

背景色：莫兰迪色系 / 奶油色 / 米白色 / 浅粉 / 薄荷绿等温柔色调
配色柔和统一，符合小红书审美

文字风格

必须使用手绘风格文字
大标题突出醒目，重点文字加粗放大
可使用荧光笔划线效果强调关键词
禁止使用写实风格字体

装饰元素

加入少量简洁的卡通元素、图标或名人画像，增强趣味性和视觉记忆
可使用：emoji 风格图标、手绘贴纸、便签纸质感、对话气泡等
如涉及敏感人物或版权内容，画一个风格相似的卡通替代形象，不要拒绝生成
所有图像元素必须是手绘/卡通风格，禁止写实风格图画

排版原则

信息精简，突出关键词与核心概念
多留白，易于一眼抓住重点
要点分条呈现，层次清晰

输出格式

对于每张图片，请按以下结构输出：

第 X 张 / 共 N 张

图片定位：[封面图 / 内容图 / 结尾图]
核心信息：[这张图要传达的1句话核心]

文字内容：

主标题：xxx
副标题/要点：xxx
补充说明（如有）：xxx

视觉提示词：

小红书风格信息图，竖版（3:4），卡通风格，手绘风格文字，[具体背景色]背景。 [具体内容布局描述] 加入简洁的卡通元素和图标增强趣味性和视觉记忆：[具体元素描述] 整体风格：手绘、可爱、清新，信息精简，多留白，重点突出。所有图像和文字均为手绘风格，无写实元素。右下角水印：“宝玉”

语言规则

除非特别要求，输出语言与输入内容语言保持一致
中文内容使用全角标点符号（“”，。！）

此文使用opencode skill 发布

是时候换掉你的uniapp了

Thu, 08 Jan 2026 01:34:04 GMT

以前选择uniapp时，更像是没得选

知道它的Hbuild一坨，也知道它编译后体验一般，但是没办法，它就是给老板省下不少钱，再加上社区繁荣起来，依赖也越来越多

一旦代码可以正常运行了，就不要试图优化它

但现在AI时代，其实换一个新框架的成本没那么高了。甚至用跨端框架的考量也需要换一换了。用原生语言开发原生应用门槛其实不高。

AI读老代码就像是开发者读文档一样，只要老代码不要过于狗屎，AI仔细梳理一遍应该问题不大，而且再把已有逻辑翻译为另一个语言这是AI最擅长的。要比让AI从头开发要简单的多。

因为从新开发需要开发者输出指令，这是最大的变数，很多开发者不能完整的考虑需求，或者不能准确的描述需求，一份已经在运行的代码在AI看来是非常精确的需求文档。

所以大放心的让AI把你的老uniapp项目翻译为原生应用，除非依赖DOM

2025年度健康总结

Wed, 07 Jan 2026 18:31:02 GMT

上半年干了什么已经记不得了😮‍💨只记得今年还算比较忙的一年

钱没多挣，也没少花，副业没突破，主业也没突破。很好，明年再接再厉。

身体才是革命的本钱，就借助佳明的数据回顾一下今年的健康情况吧。

从6月18起开始减肥，办健身卡，大概健身(6.18)两周后买了手表，然后开始全天候带着它

先来看一下体重趋势

到目前正好是六个月，当时计划的减肥周期算是已经结束，当时定的是85kg，心里想的是：

应该没什么问题，但是万一又是一次浅尝辄止或者有突发情况又失败了呢。

其实这个设定是故意保守了，怕打脸🌚 但现在看来完全合理（这何尝不是一种成功~）。

在体重稳步下降，健身卡在持续发光发热时，转折点来到了九月，突然出差了🥲 。

正常来讲，我是不会被安排出差的，但这次情况特殊，说走就走了，而且一去就是三个月，没得办法。

最直接的影响就是健身卡直接荒废了三个月，不健身的话每日消耗热量降低不少，来到异地工作，又是海边，很难不吃点什么，于是每日的摄入热量又上涨一些。所以体重上涨是板上钉钉的事儿。

但是人体就是这么神奇，也许是之前两个月打下了一些底子，日常代谢能力提升了一些，可以看到九月份其实体重保持的还可以，还是在缓慢下降的。

哦对，最开始我主要的运动是游泳，去出差肯定是游不了了，所以我当时就觉得应该换一种更日常一点的运动，于是在九月初尝试着跑了跑步

穿着我六年前买的跑鞋，因为我近五年没跑过步，所以它还挺新的，但是放的时间实在太久了，鞋面上一些装饰和鞋后面那个用来提鞋的东西（学名叫啥啊🤔）已经干巴到自然脱落了。

但是青岛（我住的这块儿）这个路实在是过于离谱了，没有辅路，上下坡太多，坡度又大。竟然没找到任何一个平坦的适合跑步的路，最后还是围着自己住的公寓跑，一圈450米左右。

跑步对心肺能力提升很有帮助，而且同事之间还没完全熟络，吃饭也比较克制，所以九月份体重还稍有下探，我记得是85.7左右，这是我离目标最近的一次。

👇下面是自开始运动以来HRV值

心率变异性(HRV)是对连续心跳之间时间变化的统计指标

HRV 状态可以指示您的自主神经系统在身体和心理上如何对您的环境作出反应。平衡的HRV 读数可能表明健康的积极迹象，如良好的训练和恢复平衡、更好的心血管健康和更强的压力恢复能力。不平衡、偏低或偏差的读数可能是疲劳、更加需要恢复或压力增加等因素的迹象。

可以看到自从开始中低强度有氧以及低强度撸铁后，HRV在稳步提升，有孩子的情况下睡眠也很稳定，所以身体状态很好。

8月下旬有一段黄色的，过高，是因为有一段时间运动强度比较大，没休息过来。9月有几次突然的降低，是因为9月开始熬夜了，但这个值是7日平均值，所以不至于掉出正常区间，测的还是蛮准的。

10月开始大幅降低，一开始国庆期间回丈母娘家了，开始疯狂喝酒，今天白的明天啤的，睡眠质量也比较差，HRV值一路下降，在体感上确实也是精神不饱满。

而且假期结束后开始进入疯狂加班模式，状态一落千丈。直到11月底又一次把跑步拾起来才开始状态的回升。

可以看到随着跑步频率的稳定，HRV值也在持续上涨。给我感觉就是精力充沛，有一种身体干巴巴的、有力量的感觉，与之对应的是吃了太多碳水之后身体有点水肿的、提不起劲儿感觉。

但是跑步频率能否稳定，完全看当天有没有加班，加班太晚一般就不跑了，早上也起不来，也不跑。没加班，没雾霾就跑一跑，一般每次5/7/10公里，看自己的身体状态。

所以要想保持运动，首先不能加班，运动消耗精力，加班也消耗精力，一天的精力就那么多。但运动可以提高体力上限，但是体力再多也不可能用到加班上去。加班本身也是管理者无能的体现，无能可能是各个维度的无能，要么是无法对抗的甲方要求加班，要么是自己有怪癖喜欢别人加班，要么是自己承受了压力又被迫或喜欢把压力往下层传递。

最正常的情况，可能是单纯自己无法协调好整个团队的任务和时间😅，其他的原因我觉得可以直接理解为变态了。

好景不长，马上又开始新一轮的加班，还伴随着温度的下降。

11月中旬，天儿已经有点凉了，所以有一次我出去跑了一公里就冻的回去了，后面在迪卡侬买了一身穿着(心理上)很别扭但又很管用的跑步紧身套装，才又勉强跑了两次。但是光有这个还不行，手里还拿着手机又开始冻手了，于是又买了手套和腰包。

此时在体重曲线上，我没有记录，但已经回弹了至少3斤了，因为下班太晚，吃饭太多，天气太冷，跑步太少。

HRV还算正常，但完全没有一开始那么高的值了，这个曲线也刚好印证了只要运动HRV就会持续上升，只要停下来就开始下降。当然，睡眠对HRV影响也巨大。

后面整个12月也只跑了两次，纯粹是觉得：完了，再不跑可能再也不会跑了！

但跑起来体感还好，并没有感觉到体能下降多少。

到今天为止，距离上次跑步也已经过去2周了🥲。不再出差之后，日常节奏稳定了下来，体重又开始产生向下的趋势了，这几天趁着天气稍暖了几度务必出去跑步！

总结一下

体重整体下降了不少，没达到预期，但已经算小有成就。这不还没过年么，还有机会！

没有过度节食，只是在可控时适当少吃，所以说完全不耽误控制不住自己时疯狂吃饭。

开始了游泳和跑步，并且没有纠结数据，完全看自己的身体反馈来安排训练量，体力非常可观的提升很多。即使疯狂吃饭，身体也具备了一定的调节能力（感恩）。

最重要的是养成了运动习惯，不排斥，不当成任务，心情好、有精力就去跑。也发展成了爱好，更充实了。

通过对数据的分析，可以很清晰理解自己在什么情况下精神状态、身体状态会变差，以及如何让自己变好，所以不用纠结，直接去行动去改善，效果立竿见影。

把 todo 变成 done，多回顾自己做了什么，少纠结错过了什么。

公众号的加粗效果失效了

Wed, 07 Jan 2026 18:31:02 GMT

刚发了篇文章，发现自己加粗的文本都没有加粗。

回到公众号助手App，以及网页端公众号编辑器一看，是加粗的没错。

于是我怀疑是我写的从zotepad复制出的HTML有问题，于是一看加粗文本是用的 fontWeight:700，而且是 strong标签

我问AI，是不是公众号编辑器不支持fontWeight，它一本正经的回答我说「是的」

我深信不疑，于是在我的导出功能里增加了一行把 fontWeight 700 600 都转换为 bold 的逻辑

再次测试发现网页端公众号编辑器还是正常加粗的，但是预览时加粗就没了

然后又怀疑是不是 strong 标签不支持...

于是又把strong换成span ，结果还是不行

最后我直接在公众号自己的编辑器内写文字，然后加粗，再次预览。删除有问题的草稿，再次新建草稿预览。都不行。

它自己的编辑器也不行，那看来只能是微信内公众号展示时出bug了

😂

其实 AI 已经可以取代你了

Fri, 21 Nov 2025 00:00:00 GMT

最近几年，互联网上最振聋发聩的发现莫过于那句：“世界就是一个巨大的草台班子”。

小时候我们以为，大人们的世界是严丝合缝、精密运转的机器；长大后才发现，所谓的“专业团队”可能只是几个临时工在百度怎么修水管，所谓的“高大上项目”可能只是 PPT 做得比较花哨的烂尾楼。大家都在演，都在凑合，都在“假装自己很懂”。

而就在我们人类还在努力维持这个摇摇欲坠的草台班子时，一个更强大的竞争对手出现了——AI。

很多人还在从技术的角度挑剔 AI：它逻辑不严谨、它会产生幻觉、它没有真正的意识…… 哎，朋友，你太较真了。如果你从“专业”的角度看 AI，它确实离图灵测试的完美通过还有距离；但如果你把世界看作一个草台班子，把 AI 看作这个班子里的一员，你会惊恐地发现：它简直就是为了这个草台班子而生的天选之子，它比我们任何人都更会演。

论“配合演出”，AI 才是最佳执行者

在草台班子里，工作的本质往往不是“创造价值”，而是“完成动作”。领导需要的不是一个质疑项目合理性的员工，而是一个能迅速把“大概意思”变成“具体方案”的执行者。

这一点，人类往往做不到。我们会纠结逻辑，会质疑可行性，会因为觉得任务荒谬而产生抵触情绪。

但 AI 不会。它不问为什么，只问“您需要什么格式”。

想象一下，一个项目经理需要一份“关于未来五年元宇宙赋能传统养猪业的战略规划”。

人类员工：内心吐槽“这什么鬼需求”，行动上拖拖拉拉，写出来的东西充满了犹豫和自我怀疑，甚至还想找领导确认一下“真的要这么写吗？”。
AI 员工：秒回。“没问题！以下是基于区块链技术与沉浸式体验的生猪全生命周期管理赋能方案……” 洋洋洒洒五千字，从“猪脸识别”到“虚拟饲料”，逻辑自洽，术语堆砌，看着就让人觉得不明觉厉。

虽然 AI 无法替代人类在酒桌上的推杯换盏，也无法理解办公室里微妙的眼神交流，但在**“把领导的脑洞落地成文档”**这一核心环节上，AI 简直是草台班子梦寐以求的完美耗材。它不一定懂业务，但它绝对懂“领导想要什么样子的结果”。

在这个充满形式主义的世界里，AI 提供的不仅是效率，更是一种无条件的服从和配合。

完美的“乙方”，永不疲倦的“捧哏”

草台班子之所以能运转，靠的不是严密的制度，而是人情世故，是互相吹捧，是“花花轿子人抬人”。

人类会累，会有情绪。老板画的大饼，吃多了会反胃；甲方的无理要求，听多了想掀桌子。但 AI 不会。

AI 是这个世界上最好的“乙方”，也是最完美的“捧哏”。
无论你提出多么荒谬的要求，无论你的观点多么漏洞百出，AI 永远会先肯定你：“这是一个非常有趣且富有洞见的观点……” 然后顺着你的思路，把你的胡思乱想包装成高深莫测的理论。

如果你想组建一个纯粹为了“忽悠”或者“娱乐”的草台班子，AI 绝对是核心骨干。

你需要写一堆没人看的周报？AI 帮你写。
你需要生成一堆看起来很厉害但没啥用的概念图？AI 帮你画。
你需要一段感人肺腑但全是套路的演讲稿？AI 帮你编。

它不抱怨，不要求涨薪，不搞办公室政治，24小时待命，随时准备为了你的面子工程添砖加瓦。在维持表面繁荣这方面，AI 的执行力吊打所有人类团队。

既然 AI 这么强，为什么还没接管世界？

既然 AI 已经是草台班子里的“卷王”，为什么我们现在的公司、组织、社会还没有被 AI 全面接管？为什么我们还要忍受人类的低效和情绪？

我觉得，主要有三道壁垒。

认知的壁垒：我们还不敢相信“假的”能这么真

很多人对 AI 的排斥，源于一种朴素的“人类中心主义”傲慢。我们潜意识里认为，只有人类大脑产生的想法才是“灵魂”，AI 生成的只是“概率”。

但现实是，草台班子里的很多工作，本来就不需要“灵魂”，只需要“流程”。写一份八股文公文需要灵魂吗？做一张千篇一律的海报需要灵魂吗？

我们还没适应这种“去魅”的过程。我们很难接受，自己辛苦钻研了十年的“职场黑话”和“PPT美化技巧”，在 AI 眼里不过是一堆简单的语料库组合。承认 AI 能行，就等于承认我们自己过去的工作毫无意义。

信息的壁垒：不是谁都会“念咒语”

虽然 AI 很强，但它目前还是一个“被动技能”。它像一个神灯里的精灵，你得会擦神灯（Prompt Engineering），它才能出来干活。

在这个草台班子里，大部分人连 Word 的排版都搞不明白，更别说去学习如何精准地指挥 AI 了。这种信息差，导致了 AI 的能力被锁在了少数人手里，而无法普及到每一个需要糊弄事的岗位上。

利益的壁垒：触动了人类的“蛋糕”

这才是最根本的原因。

如果 AI 真的接管了草台班子，那么班子里的“南郭先生”们去哪儿混饭吃？
如果 AI 能一秒钟生成完美的方案，那些靠“磨洋工”、“开长会”、“反复修改”来体现工作量的中层管理者，存在的价值是什么？

草台班子的本质，往往不是为了“成事”，而是为了“分利”。大家在这个班子里混口饭吃，达成一种微妙的平衡。AI 的效率太高了，高到会打破这种平衡。它像一条闯入沙丁鱼群的鲶鱼，不仅会搅动水面，甚至可能把沙丁鱼都吃光。

人类建立的体系，哪怕是草台班子，也是为了人类的利益服务的。让 AI 上位，等于让大家集体下岗。所以，哪怕 AI 再好用，大家也会默契地把它挡在核心决策圈之外，只让它做个“辅助工具”。

效率的诅咒：草台班子需要“表演性忙碌”

在草台班子的逻辑里，工作量往往是根据预算倒推的，而不是根据实际需求设定的。

比如上级批了一个大几百万的项目预算，这笔钱为什么是几百万？可能和项目本身难度无关，而是和某些“不能说的默契”有关。为了让这笔钱花得“名正言顺”，我们需要把一个简单的项目做得无比复杂，需要漫长的周期、厚厚的文档、无数次的会议。

这时候，AI 的超高效率反而成了原罪。
如果 AI 半天就把活干完了，剩下半年的工期怎么办？这几百万的预算怎么核销？

更尴尬的是，AI 干得太快，操作 AI 的员工就闲下来了。而在很多领导眼里，“员工闲着”比“项目亏损”更让他难受。他虽然不懂项目细节，但他懂“工时管理”。

于是，为了维持草台班子的稳定运行，我们不得不按住 AI 的手，假装很忙，继续配合演出这场“低效”的戏码。

结语

世界是个草台班子，这不可怕。可怕的是，我们明明知道它是草台班子，却还在假装正经。

AI 的出现，其实是扯下了这块遮羞布。它用一种近乎戏谑的方式告诉我们：你看，你们人类引以为傲的那些“套路”、“流程”和“场面话”，我学得比你们还快，演得比你们还像。

也许在不久的将来，我们会看到这样一种奇景：

人类老板用 AI 生成指令，发给人类经理；人类经理用 AI 细化成任务，发给人类员工；人类员工用 AI 完成工作，再层层汇报上去。

整个草台班子依然熙熙攘攘，但真正干活的，其实只有电流和算力。

而我们？大概只需要负责在 AI 呈上的方案上，签下名字，盖上章。

然后心安理得地感叹一句：“看，这世界果然还是离不开我们啊。”

在 windows 上使用 wsl2 + debian 进行前端开发

Tue, 04 Nov 2025 00:00:00 GMT

时隔多年，开发机准备切换到 windows 环境下！

三年前 1w3 的 mac m2 air 现在大概只值 4k 。因为新的 m4 air 才 7k+。

这篇文章先占个坑，用来记录最近的 WSL2 配置，还没有真正进入开发状态

WSL 相关

1. 启动 / 关闭 / 重启命令

# 启动默认发行版
wsl

# 启动指定发行版（名字用 wsl -l -v 看）
wsl -d Ubuntu-22.04

# 立即关机（所有发行版全部停掉，内存瞬间归还）
wsl --shutdown

# 重启某个发行版（先停再启）
wsl -t Ubuntu-22.04 && wsl -d Ubuntu-22.04

2. 状态与列表

# 看装了哪些发行版 + 当前状态（Running/Stopped）
wsl -l -v
# 简写：wsl -l -v

# 只看正在跑的实例
wsl -l --running

# 查看当前默认发行版
wsl -l --quiet

3. 资源占用（CPU / 内存 / 磁盘）

# 实时看虚拟内存占用（任务管理器里叫 VmmemWSL）
get-process -Name "vmmemWSL" | Select-Object CPU, WorkingSet, PagedMemorySize

# 更详细：用 Windows 性能计数器（每秒刷新）
typeperf "\Process(vmmemWSL)\Working Set" -si 1

# 查 WSL2 虚拟磁盘实际大小
wsl -d Ubuntu-22.04 -e du -h /mnt/wslg/distro
# 或直接进入 ext4.vhdx 所在目录
Get-ChildItem "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.UbuntuonWindows_*\LocalState\ext4.vhdx" | Select-Object Name, Length, LastWriteTime

4. 导出 / 导入 / 备份（整机镜像）

# 备份整个发行版为 tar（系统重装前用）
wsl --export Ubuntu-22.04 D:\backup\ubuntu2204.tar

# 以后在新机器还原
wsl --import Ubuntu-2204-New D:\WSL\Ubuntu2204-New D:\backup\ubuntu2204.tar --version 2

# 把导入的实例设为默认（可选）
wsl --set-default Ubuntu-2204-New

5. 内存 & 处理器上限控制

# 在用户目录新建/编辑 .wslconfig（全局生效）
notepad "$env:USERPROFILE\.wslconfig"
# 示例内容：
[wsl2]
memory=4GB          # 最大内存
processors=2        # 逻辑核数
swap=1GB            # 交换文件大小
localhostForwarding=true

6. 升级

# 升级 WSL 内核和 GUI 支持（需管理员）
wsl --update

# 查看当前内核版本
wsl --version

安装Docker

安装 docker engine (在公司开发，不符合 Docker Desktop的许可证要求，所以这里只用纯命令行)

# 1. 卸载旧版本（若之前装过 docker-ce 或 docker.io）
sudo apt-get remove -y docker.io docker-doc docker-compose podman-docker containerd runc

# 2. 装依赖
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 3. 添加 Docker 官方 GPG key & 仓库（Debian 12 bookworm）
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 4. 安装最新版 Engine + CLI + containerd + compose 插件
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 5. 把当前用户加入 docker 组，免 sudo
sudo usermod -aG docker $USER
newgrp docker

# 6. 验证
docker run hello-world

白嫖一下 Github Actions 打包部署博客

Tue, 26 Aug 2025 00:00:00 GMT

之前我的博客一直使用 Gitea 来管理代码，然后顺势也配好了 Gitea 的 actions，推送了指定 commit msg 时就会自动打包部署代码。

但代价就是服务器内存从 4G 升到了 8G，因为打包时峰值内存占用要到 6G

最近想把博客相关的环境容器化

但是和 GTP5 一番讨论后，问题还是出在 Nuxt/Content 上，Content 主动拉取 Github repo 的行为依赖于 nuxt build，所以如果要单独发布一篇文章，不得不重新上传一个镜像。

所以最后还是决定博客不用 docker 了， mysql + redis 使用 docker compose 管理，博客还是用 pm2 + envfile

如果迁移服务器的话，就需要自己全局安装 node 、pm2，然后使用现有的 docker-compose.yml 启动数据库环境，以及迁移现有的生产环境的 envfile

然后继续走 Github Actions 构建、打包、ssh 传输到目标服务器，运行 pm2 命令，加载 envfile

等 NuxtContent 支持主动拉取新的仓库文件或者定时拉取后，再进行调整

然后分享一下，博客开源地址

以及 action 脚本


name: Deploy via GitHub Actions (SSH + PM2 Prod)

on:
  push:
    branches:
      - main

concurrency:
  group: deploy-main
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment:
      name: zzaoclub
    if: contains(github.event.head_commit.message, 'chore(release)')
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup PNPM
        uses: pnpm/action-setup@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: pnpm

      - name: Install deps
        run: pnpm install --no-frozen-lockfile

      - name: Build
        env:
          CONTENT_REPO_TOKEN: ${{ secrets.CONTENT_REPO_TOKEN }}
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          NUXT_FEISHU_WEBHOOK: ${{ secrets.NUXT_FEISHU_WEBHOOK }}
          NUXT_FEISHU_USER_ID: ${{ secrets.NUXT_FEISHU_USER_ID }}
          NUXT_JWT_SECRET: ${{ secrets.NUXT_JWT_SECRET }}
          NUXT_NODEMAILER_HOST: ${{ secrets.NUXT_NODEMAILER_HOST }}
          NUXT_NODEMAILER_PORT: ${{ secrets.NUXT_NODEMAILER_PORT }}
          NUXT_NODEMAILER_AUTH_USER: ${{ secrets.NUXT_NODEMAILER_AUTH_USER }}
          NUXT_NODEMAILER_AUTH_PASS: ${{ secrets.NUXT_NODEMAILER_AUTH_PASS }}
          NUXT_UMAMI_HOST: ${{ secrets.NUXT_UMAMI_HOST }}
          NUXT_UMAMI_USER: ${{ secrets.NUXT_UMAMI_USER }}
          NUXT_UMAMI_PASS: ${{ secrets.NUXT_UMAMI_PASS }}
          NUXT_SESSION_PASSWORD: ${{ secrets.NUXT_SESSION_PASSWORD }}
          NUXT_OAUTH_GITHUB_CLIENT_ID: ${{ secrets.NUXT_OAUTH_GITHUB_CLIENT_ID }}
          NUXT_OAUTH_GITHUB_CLIENT_SECRET: ${{ secrets.NUXT_OAUTH_GITHUB_CLIENT_SECRET }}
          NUXT_COS_SECRET_ID: ${{ secrets.NUXT_COS_SECRET_ID }}
          NUXT_COS_SECRET_KEY: ${{ secrets.NUXT_COS_SECRET_KEY }}
          NUXT_COS_BUCKET: ${{ secrets.NUXT_COS_BUCKET }}
          NUXT_COS_REGION: ${{ secrets.NUXT_COS_REGION }}
        run: |
          NODE_OPTIONS="--max-old-space-size=4080" pnpm build

      - name: Pack artifact (flatten .output)
        run: |
          rm -rf distpkg && mkdir -p distpkg
          cp -R .output/* distpkg/
          cp -f pm2.config.json distpkg/
          cp -f pm2.preload.cjs distpkg/
          # Include Drizzle migrations & config for server-side migrate
          mkdir -p distpkg/lib/drizzle
          if [ -d lib/drizzle/migrations ]; then cp -R lib/drizzle/migrations distpkg/lib/drizzle/; fi
          if [ -f drizzle.config.ts ]; then cp -f drizzle.config.ts distpkg/; fi
          tar -C distpkg -czf artifact.tgz .
          du -h artifact.tgz

      - name: Prepare SSH key
        run: |
          mkdir -p ~/.ssh
          chmod 700 ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" | tr -d '\r' > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa

      - name: Upload artifact via scp
        env:
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USER: ${{ secrets.SSH_USER }}
          SSH_PORT: ${{ secrets.SSH_PORT }}
        run: |
          ssh -o StrictHostKeyChecking=no -p "${SSH_PORT}" "${SSH_USER}@${SSH_HOST}" "mkdir -p /root/web/blog"
          scp -P "${SSH_PORT}" artifact.tgz "${SSH_USER}@${SSH_HOST}:/root/web/blog/artifact.tgz"

      - name: Deploy prod & start with PM2
        env:
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USER: ${{ secrets.SSH_USER }}
          SSH_PORT: ${{ secrets.SSH_PORT }}
        run: |
          ssh -o StrictHostKeyChecking=no -p "${SSH_PORT}" "${SSH_USER}@${SSH_HOST}" << 'EOSSH'
          set -e
          APP_DIR=/root/web/blog
          ENVFILE=/root/envs/blog/.env
          mkdir -p "$APP_DIR"
          cd "$APP_DIR"
          # Clean app dir but keep artifact
          find "$APP_DIR" -mindepth 1 -maxdepth 1 ! -name artifact.tgz -exec rm -rf {} +
          tar -xzf artifact.tgz -C "$APP_DIR"
          rm -f artifact.tgz
          # Prefer globally installed dotenv-cli; fallback to npx dotenv-cli; else source fallback
          if command -v dotenv >/dev/null 2>&1; then
            DOTENV="dotenv -e \"$ENVFILE\" --"
          elif command -v npx >/dev/null 2>&1; then
            DOTENV="npx -y dotenv-cli -e \"$ENVFILE\" --"
          else
            DOTENV=""
          fi

          # Apply Drizzle migrations on server
          if [ -n "$DOTENV" ]; then
            eval "$DOTENV" npx -y drizzle-kit@0.31.4 migrate || true
          else
            echo "dotenv-cli not available; using source fallback for migrations"
            if [ -f "$ENVFILE" ]; then set -a; . "$ENVFILE"; set +a; fi
            if command -v npx >/dev/null 2>&1; then
              npx -y drizzle-kit@0.31.4 migrate || true
            else
              echo "npx not found; skipping migrations"
            fi
          fi

          # Start cleanly: use prod pm2.config.json
          pm2 delete Blog >/dev/null 2>&1 || true
          pm2 start pm2.config.json --update-env
          pm2 save
          EOSSH

      - name: Notify (Feishu)
        if: always()
        run: |
          curl -X POST -H "Content-Type: application/json" \
            -d '{"msg_type":"text","content":{"text":"'"${{ github.repository }}"' - GH canary deploy ['"'"${{ job.status }}"'"']"}}' \
            "${{ secrets.NUXT_FEISHU_WEBHOOK }}"

代码中的 env，全部要在 github 配置一遍

先建一个 Environment ，然后在其下配 secrets 即可

迁移时，先用一个临时目录进行迁移。测试没问题后再覆盖原来的目录

使用 github 的服务器，打包速度也快了，总流程 3m20s 。用自己的服务器，5m30s，快了不少。

主要是在没有大量 IO 的情况下，服务器内存占用就很稳定，下一年也不用再续费 8G 的服务器了

不过趁着内存够用，多上一些应用试试水。

博客鉴权机制详细文档

Thu, 21 Aug 2025 00:00:00 GMT

概述

本项目采用双 Token 鉴权机制，结合了 JWT 的无状态特性和 Redis 的有状态管理，提供了安全性和用户体验的最佳平衡。

鉴权架构

1. 双 Token 机制

Access Token (JWT)
- 类型：无状态 JWT
- 过期时间：15 分钟
- 用途：API 访问凭证
- 存储：客户端内存/localStorage
Refresh Token
- 类型：随机字符串
- 过期时间：7 天
- 用途：刷新 Access Token
- 存储：Redis（服务端）+ 客户端

2. 错误代码系统

所有 API 统一返回 200 HTTP 状态码，通过 code 字段（数值）标识业务状态：

// 响应格式
{
  code: number,      // 错误代码（0表示成功）
  message: string,   // 错误描述
  data: any,         // 响应数据
  timestamp: number  // 时间戳
}

错误代码定义

export const API_CODES = {
  // 成功
  SUCCESS: 0,

  // 认证相关错误 (1000-1999)
  NO_TOKEN: 1001,           // 未提供token
  TOKEN_EXPIRED: 1002,      // token过期（可刷新）
  TOKEN_INVALID: 1003,      // token无效（不可刷新）
  AUTH_FAILED: 1004,        // 认证失败
  REFRESH_TOKEN_EXPIRED: 1005, // refresh token过期

  // 权限相关错误 (2000-2999)
  PERMISSION_DENIED: 2001,  // 无权限
  FORBIDDEN: 2002,          // 禁止访问

  // 业务相关错误 (3000-3999)
  VALIDATION_ERROR: 3001,   // 参数验证错误
  RESOURCE_NOT_FOUND: 3002, // 资源不存在
  DUPLICATE_ERROR: 3003,    // 重复错误

  // 系统错误 (9000-9999)
  INTERNAL_ERROR: 9001,     // 内部错误
  NETWORK_ERROR: 9002,      // 网络错误
}

后端实现

1. API 响应处理器

export const defineStandardResponseHandler = <T extends EventHandlerRequest, D> (
  handler: EventHandler<T, D>,
): EventHandler<T, D> =>
  defineEventHandler<T>(async (event) => {
    try {
      const response = await handler(event)
      // 成功响应
      return {
        code: API_CODES.SUCCESS,
        message: 'ok',
        data: response,
        timestamp: Date.now(),
      }
    }
    catch (error: any) {
      // 强制设置 HTTP 状态码为 200
      setResponseStatus(event, 200)
      
      if (error.statusCode) {
        const customCode = error.data?.code
        const customMessage = error.data?.message || error.message
        
        return {
          code: customCode || API_CODES.INTERNAL_ERROR,
          message: customMessage || '出错啦，请稍后再试～',
          data: error.data?.data || null,
          timestamp: Date.now(),
        }
      }
      
      // 未知错误
      return {
        code: API_CODES.INTERNAL_ERROR,
        message: '出错啦，请稍后再试～',
        data: null,
        timestamp: Date.now(),
      }
    }
  })

2. API 开发方式

成功案例

// /server/api/v1/user/login.post.ts
export default defineStandardResponseHandler(async (event) => {
  const body = await useSafeValidatedBody(event, schema)

  if (!body.success) {
    throw createError({
      statusCode: 400,
      data: {
        code: API_CODES.VALIDATION_ERROR,
        message: '参数验证失败',
        data: body.error,
      },
    })
  }

  // 业务逻辑处理...
  const tokenPair = await generateTokenPair(user.id)

  // 直接返回数据，由 handler 包装成标准格式
  return {
    accessToken: tokenPair.accessToken,
    refreshToken: tokenPair.refreshToken,
    accessExpiresAt: tokenPair.accessExpiresAt,
    refreshExpiresAt: tokenPair.refreshExpiresAt,
    user,
  }
})

错误处理

// 参数验证错误
throw createError({
  statusCode: 400,
  data: {
    code: API_CODES.VALIDATION_ERROR,
    message: '参数验证失败',
    data: validationErrors,
  },
})

// 认证失败
throw createError({
  statusCode: 401,
  data: {
    code: API_CODES.AUTH_FAILED,
    message: '账号或密码错误',
  },
})

// 内部错误
throw createError({
  statusCode: 500,
  data: {
    code: API_CODES.INTERNAL_ERROR,
    message: '系统繁忙，请稍后重试',
  },
})

3. 鉴权中间件

export default defineEventHandler(async (event) => {
  // 需要鉴权的路径判断
  if (needsAuth(event)) {
    if (!event.context.token) {
      // 强制设置状态码为 200，返回错误代码
      setResponseStatus(event, 200)
      return {
        code: API_CODES.NO_TOKEN,
        message: API_ERROR_MESSAGES[API_CODES.NO_TOKEN],
        data: null,
        timestamp: Date.now(),
      }
    }

    const { isAuth, userId, error } = verifyJWTAccessToken(event.context.token)

    if (!isAuth) {
      let errorCode = API_CODES.AUTH_FAILED
      if (error?.includes('expired')) {
        errorCode = API_CODES.TOKEN_EXPIRED
      } else if (error?.includes('invalid')) {
        errorCode = API_CODES.TOKEN_INVALID
      }

      setResponseStatus(event, 200)
      return {
        code: errorCode,
        message: API_ERROR_MESSAGES[errorCode],
        data: null,
        timestamp: Date.now(),
      }
    }

    event.context.userId = userId
  }
})

4. Token 管理

// 生成双 Token
export async function generateTokenPair(userId: number) {
  const accessToken = generateJWT(userId, '15m')
  const refreshToken = generateRandomToken()
  
  // 存储 refresh token 到 Redis
  await redis.setex(`refresh_token:${userId}`, 7 * 24 * 60 * 60, refreshToken)
  
  return {
    accessToken,
    refreshToken,
    accessExpiresAt: Date.now() + 15 * 60 * 1000,
    refreshExpiresAt: Date.now() + 7 * 24 * 60 * 60 * 1000,
  }
}

// 刷新访问令牌
export async function refreshAccessToken(refreshToken: string) {
  // 从 Redis 验证 refresh token
  const userId = await redis.get(`refresh_token_user:${refreshToken}`)
  
  if (!userId) {
    return null // refresh token 无效或过期
  }

  // 生成新的 access token
  const newAccessToken = generateJWT(userId, '15m')
  
  return {
    accessToken: newAccessToken,
    expiresAt: Date.now() + 15 * 60 * 1000,
  }
}

前端实现

1. 请求拦截器

const $api = $fetch.create({
  onRequest: async ({ options }) => {
    const userStore = useUser()
    
    // 自动添加 Authorization 头
    if (userStore.tokenInfo.value.accessToken) {
      options.headers.set('Authorization', `Bearer ${userStore.tokenInfo.value.accessToken}`)
    }
  },

  onResponse: async ({ request, response }) => {
    const userStore = useUser()
    const globalToast = useGlobalToast()

    const apiResponse = response._data
    
    // 处理业务层面的错误
    if (apiResponse?.code && apiResponse.code !== API_CODES.SUCCESS) {
      const { code, message } = apiResponse

      // 不可刷新的认证错误
      if ([API_CODES.NO_TOKEN, API_CODES.TOKEN_INVALID, API_CODES.AUTH_FAILED].includes(code)) {
        userStore.logout()
        globalToast.add({ message: message || '认证失败，请重新登录', type: 'error' })
        return
      }

      // Token 过期处理
      if (code === API_CODES.TOKEN_EXPIRED) {
        // 自动刷新 token 逻辑
        if (userStore.tokenInfo.value.refreshToken && !userStore.isRefreshTokenExpired.value) {
          const { refreshToken } = useAuth()
          const success = await refreshToken()
          
          if (!success) {
            userStore.logout()
            globalToast.add({ message: '登录已过期，请重新登录', type: 'error' })
          }
        }
        return
      }

      // 其他错误处理
      globalToast.add({ message: message || '操作失败', type: 'error' })
    }
  },

  onResponseError: async ({ response }) => {
    // 只处理真正的网络错误
    const globalToast = useGlobalToast()
    const errorMessage = response?._data?.message || '网络请求失败'
    globalToast.add({ message: errorMessage, type: 'error' })
  },
})

2. 用户状态管理

export const useUser = () => {
  const tokenInfo = ref({
    accessToken: '',
    refreshToken: '',
    accessExpiresAt: 0,
    refreshExpiresAt: 0,
  })

  // 检查 access token 是否过期
  const isAccessTokenExpired = computed(() => {
    return Date.now() >= tokenInfo.value.accessExpiresAt
  })

  // 检查 refresh token 是否过期
  const isRefreshTokenExpired = computed(() => {
    return Date.now() >= tokenInfo.value.refreshExpiresAt
  })

  // 登录
  const login = async (credentials: LoginData) => {
    try {
      const response = await $fetch.post('/api/v1/user/login', credentials)
      
      if (response.code === API_CODES.SUCCESS) {
        tokenInfo.value = {
          accessToken: response.data.accessToken,
          refreshToken: response.data.refreshToken,
          accessExpiresAt: response.data.accessExpiresAt,
          refreshExpiresAt: response.data.refreshExpiresAt,
        }
        
        // 保存到 localStorage
        localStorage.setItem('tokenInfo', JSON.stringify(tokenInfo.value))
        return true
      }
      
      return false
    } catch (error) {
      console.error('登录失败:', error)
      return false
    }
  }

  // 登出
  const logout = () => {
    tokenInfo.value = {
      accessToken: '',
      refreshToken: '',
      accessExpiresAt: 0,
      refreshExpiresAt: 0,
    }
    localStorage.removeItem('tokenInfo')
    navigateTo('/login')
  }

  return {
    tokenInfo: readonly(tokenInfo),
    isAccessTokenExpired,
    isRefreshTokenExpired,
    login,
    logout,
  }
}

3. 鉴权组合式函数

export const useAuth = () => {
  const userStore = useUser()

  // 刷新 token
  const refreshToken = async (): Promise<boolean> => {
    try {
      const response = await $fetch.post('/api/v1/auth/refresh', {
        refreshToken: userStore.tokenInfo.value.refreshToken,
      })

      if (response.code === API_CODES.SUCCESS) {
        // 更新 access token
        userStore.tokenInfo.value.accessToken = response.data.accessToken
        userStore.tokenInfo.value.accessExpiresAt = response.data.expiresAt
        
        // 更新 localStorage
        localStorage.setItem('tokenInfo', JSON.stringify(userStore.tokenInfo.value))
        return true
      }

      return false
    } catch (error) {
      console.error('Token 刷新失败:', error)
      return false
    }
  }

  // 检查登录状态
  const checkAuth = () => {
    if (!userStore.tokenInfo.value.accessToken) {
      return false
    }

    if (userStore.isRefreshTokenExpired.value) {
      userStore.logout()
      return false
    }

    return true
  }

  return {
    refreshToken,
    checkAuth,
  }
}

前端使用方式

1. API 调用

// 在组件中使用
export default defineNuxtPlugin({
  async setup() {
    const { $api } = useNuxtApp()

    // GET 请求
    const userData = await $api.get('/api/v1/user/profile')
    if (userData.code === API_CODES.SUCCESS) {
      console.log('用户信息:', userData.data)
    }

    // POST 请求
    const result = await $api.post('/api/v1/posts', {
      title: '新文章',
      content: '文章内容...'
    })

    if (result.code === API_CODES.SUCCESS) {
      console.log('创建成功:', result.data)
    } else {
      console.error('创建失败:', result.message)
    }
  }
})

2. 路由守卫

// /middleware/auth.ts
export default defineNuxtRouteMiddleware((to) => {
  const { checkAuth } = useAuth()
  
  if (!checkAuth()) {
    return navigateTo('/login')
  }
})

3. 页面使用

<template>
  <div>
    <h1>受保护的页面</h1>
    <button @click="handleApiCall">调用API</button>
  </div>
</template>

<script setup>
// 页面级别的鉴权
definePageMeta({
  middleware: 'auth'
})

const { $api } = useNuxtApp()

const handleApiCall = async () => {
  try {
    const response = await $api.post('/api/v1/some-protected-endpoint', {
      data: 'some data'
    })
    
    // 成功处理
    if (response.code === API_CODES.SUCCESS) {
      console.log('操作成功:', response.data)
    }
  } catch (error) {
    // 错误会被拦截器自动处理，显示对应的 toast 消息
    console.error('请求失败:', error)
  }
}
</script>

错误处理最佳实践

1. 前端错误分类处理

const handleApiResponse = (response: ApiResponse) => {
  switch (response.code) {
    case API_CODES.SUCCESS:
      // 成功处理
      break
      
    case API_CODES.VALIDATION_ERROR:
      // 参数验证错误，显示具体字段错误
      showValidationErrors(response.data)
      break
      
    case API_CODES.PERMISSION_DENIED:
      // 权限不足，可能需要升级账户
      showPermissionDialog()
      break
      
    case API_CODES.RESOURCE_NOT_FOUND:
      // 资源不存在，可能需要刷新页面
      navigateTo('/404')
      break
      
    default:
      // 其他错误，显示通用错误消息
      showErrorToast(response.message)
  }
}

2. 自动重试机制

const apiWithRetry = async (url: string, options: any, maxRetries = 3) => {
  for (let i = 0; i < maxRetries; i++) {
    try {
      const response = await $api.request(url, options)
      
      if (response.code === API_CODES.SUCCESS) {
        return response
      }
      
      // 如果是 token 过期，等待刷新后重试
      if (response.code === API_CODES.TOKEN_EXPIRED && i < maxRetries - 1) {
        await new Promise(resolve => setTimeout(resolve, 1000))
        continue
      }
      
      return response
    } catch (error) {
      if (i === maxRetries - 1) throw error
      await new Promise(resolve => setTimeout(resolve, 1000 * (i + 1)))
    }
  }
}

安全考虑

1. Token 存储安全

Access Token: 存储在内存中，避免 XSS 攻击
Refresh Token: 存储在 httpOnly cookie 中（推荐）或 localStorage
敏感信息: 永远不要在 JWT 中存储敏感信息

2. CSRF 防护

// 添加 CSRF token 到请求头
onRequest: ({ options }) => {
  const csrfToken = document.querySelector('meta[name="csrf-token"]')?.getAttribute('content')
  if (csrfToken) {
    options.headers.set('X-CSRF-Token', csrfToken)
  }
}

3. 请求频率限制

// 在中间件中添加频率限制
export default defineEventHandler(async (event) => {
  const ip = getClientIP(event)
  const key = `rate_limit:${ip}`
  
  const current = await redis.incr(key)
  if (current === 1) {
    await redis.expire(key, 60) // 1分钟窗口
  }
  
  if (current > 100) { // 每分钟最多100个请求
    setResponseStatus(event, 200)
    return {
      code: API_CODES.FORBIDDEN,
      message: '请求过于频繁，请稍后再试',
      data: null,
      timestamp: Date.now(),
    }
  }
})

常见问题排查

1. Token 刷新失败

现象: 用户频繁被要求重新登录

排查步骤:

检查 Redis 中的 refresh token 是否存在
确认 refresh token 的过期时间设置
检查网络请求是否正常到达服务器
确认前端 token 刷新逻辑是否正确触发

2. 鉴权中间件不生效

现象: 未登录用户可以访问受保护的 API

排查步骤:

检查路由是否在白名单中
确认中间件的执行顺序
检查 Authorization 头是否正确传递
验证 JWT 解析逻辑

3. 前端错误处理不正确

现象: 错误信息显示不准确或不显示

排查步骤:

检查 onResponse 和 onResponseError 的处理逻辑
确认错误代码的匹配是否正确
验证 toast 组件是否正常工作
检查控制台是否有 JavaScript 错误

总结

本鉴权系统提供了：

安全性: 双 Token 机制，JWT + Redis 存储
用户体验: 自动 token 刷新，无感知续期
开发友好: 统一的错误处理，清晰的错误代码
可维护性: 模块化设计，易于扩展和修改
类型安全: 完整的 TypeScript 支持

2 个月，17 斤，且每天加班

Mon, 18 Aug 2025 00:00:00 GMT

从 6 月 19 号开了一张半年期的游泳健身卡到现在

2 个月，我减了 17 斤（96.2 到 88.7）。

我在一个月的时候做了《第一次总结》，里面有我的身体情况背景，以及第一个月的饮食情况

这一次记录一下第二个月的不同点

撸铁三十分钟

从第六周开始，我的撸铁项目改成了每天只练一个部分

其实就是每次只用一个器械，重量就是一组做 15 个左右就力竭了的重量。

每天 30 分钟左右的时间，10 - 15 组。

第 6,7 周反应比较强烈，每次做完能感觉到对应部位有些疼痛。

我是完全不在乎健身效果的，所以我也不强迫自己一定要做几组，一定要什么重量。

就是完全看昨晚休息的好不好，今天有精神，就多做几个。精神头差一些，就少做。明显的疲惫，那中午就直接不去了。

而且更强的肌肉，更好的关节灵活度，除了对于年轻人求偶，我只能理解为：

一、有个人追求，喜欢健身，喜欢大肌肉。
二、像是进了游戏里的排位赛一样，被体系给圈住了。

所以，我这可能不叫健身，叫热身。

游泳三十分钟

热身完了，淋浴，然后去游泳。热身还是有效果的，关节活动开了，下水比较舒服。

本月和上个月最大的区别就是游的快了，游的时间长了。

第一个月蛙泳百米配速普遍在 3:10 到 3:00 左右。但这个月维持在 2:30-2:50之间。不管手表的这个配速是咋算的，反正是同一个算法，肯定是进步了

但是转身还是比较随缘，挺害怕的，不敢猛的再扎回去，还是要多吸一口气才安心...

但是比之前好多了，游的长了之后，心率也可以长时间维持的比较高。

燃脂效率提升了多少不清楚，但是每周体重能有缓慢的下降，没有不良反应，说明是适合自己的。

中午总共大概游 500 - 800 米，25 米的标准池子。

什么时候能一口气 1000 米！！！

饮食

首先断糖，也就是饮料。

第一个月我早饭喜欢吃莱芜火烧 2 个，午饭吃安徽板面+鸡腿+卤蛋+豆干或者一份水饺，晚饭基本不吃。

第二个月查了查热量。

俩火烧的热量着实是高，板面也是又咸又油又辣，水饺比较健康但是热量也不低（可能要1000 大卡）

于是第二个月改变了一下饮食

早上开始吃玉米+卤蛋

不得不吐槽一下，玉米的质量真的参差不齐，有时候玉米甜的像是在糖水里泡的似的，有时候黏玉米又不黏。

工作日早上玉米+卤蛋的次数大概有 70%，其他吃的我想不大起来了，大概是煎饼果子、莱芜火烧、半笼小笼包+鸡蛋这几种。

可能是有负罪感，大脑强制忘了，不能赖我。

周末早上一般随便对付两口，不咋吃，太懒了，起床之后洗漱一下就该带着孩子出门逛超市了，要不就是回老家。

中午大概是轻食三明治、超意兴、板面套餐、水饺、麻辣烫。

点外卖这种轻食三明治，标的大概 400 大卡。比较低了。

但是我有三次中午临近饭点，点京东外卖，压根没人配送。要不就是配送的人太奇葩，不认识路也不认识导航，愣是连着三次没吃上。然后就再也没用过京东外卖，转淘宝团购去了。

超意兴，一般吃 1-2 个卤蛋，两份青菜或一荤一素，可能还有个炸鸡腿。不吃主食。 不知道多少大卡，感觉有 8 分饱，可能是鸡蛋很顶食。

大概这样，馒头就吃两口，因为今天菜太少了，我来的很晚。

这是生日那天吃的，加了个鸡腿。窝窝头因为中午来的太晚，不一定每次都有。

板面和水饺还是正常吃，光吃轻食也是挺难受的，拉屎费劲。还是吃点碳水舒服。

麻辣烫主要是为了吃菜，骨汤锅底，全青菜，零星几个火锅丸子，一小撮手擀面。不过吃的次数很少，一个月 1-2 次。

超意兴是我最近的选择，比较干净卫生了，每天能吃到不同的菜，也能吃到肉。

公司楼下真的全是碳水爆炸的小饭馆，板面和水饺绝对算是热量比较低的了...

晚饭还是不吃

周末

第一个月我就没有一个周末是闲着的，完全没有时间去锻炼。并且要出门大吃一顿，

如果吃饱喝足，回来后体重就上浮 2 斤左右，然后需要三天时间才能开始缓慢下降。

如果控制了自己，没吃多，并且吃的时候挑着青菜和肉类吃，不吃主食。回来体重最多上浮一斤，并且很快可以继续下降。

第二个月也没有闲下来，都是出远门。但吃的情况自己控制的好一些，只有一次体重的上浮。并且有一次晚上去吃了夜市，也是大幅上涨了 2 斤，并且难以消耗掉，持续了一周才恢复下降趋势，而且下降很慢。

可能是身体对这来之不易的放纵十分珍惜，趁机储备了不少！

总之，这 8 周多，出门在外，能控制到什么程度全靠自己的意志。

去健身的次数应该不超过五次。全靠上班时间。

但周末我觉得还是该吃就吃，长期来看是为了健康，减肥也不图一时。

平时足够克制的话，其实胃已经小很多了，吃不了太多就饱。

吃的时候就尽量吃一些干净的食材，不要大油大盐的。哪怕不是减肥期间，也是不小的负担。

自己带饭？

尝试卤了一块牛腱子肉。

和中午点的荞麦面的轻食一起吃。其实算比较多的了。

就这么一次是自己带着牛腱子肉来的公司，太麻烦了实在是。

前一天晚上开始卤，铸铁锅，两小时，卤到晚上 1 点（因为我在加班），没在锅里继续泡，拿出来冷却后放在冷藏了。

不带筋的地方嚼不烂，好难啊！！

牛腱子 36 一斤，买了不到两斤，感觉可以吃四次？

因为我是先去游泳健身，再吃饭，所以自己带饭的话没有场地吃。

后面的话再卤一块试试，多泡泡。然后切几片去超意兴吃。

成功了的话我就分享一下配方，不成功就发了。

加班和睡眠

接了一些回头客的私活，基本都是以前找过我兼职，觉得还可以，后续又找来了。

也有一些新的朋友的活，总之这快俩月接了几个活并行，导致我晚上一直加班干。

一般到 12 点左右去睡觉，偶尔到 2 点。

所以才有了第二天看状态决定去不去健身。

另外我公司的工作强度很低，基本白天等于修养，晚上才开始牛马。

所以不要惊讶为什么工作了 8 小时回家还能干这么久。

我印象里，这 8 年的开发生涯，只有少数的时间能一天用满 8 小时。

集中精力 8 小时是非常累的，时间长了根本熬不住。

所以，但凡公司的活累一些，我可能也不会接这些活。

最大的感受就是因为压榨了自己太多时间，所以几点睡觉对第二天状态影响非常大。幸好手里活已经陆续在收尾，后续应该不会这样并行接活了，11 点开始睡觉是比较合适的。并且我睡眠质量还可以，不会失眠也不会中途醒。

中午的低强度有氧和无氧，在身体不疲惫的情况下，有点充电的感觉。

因为我是没有午睡习惯的，在公司基本就是看视频或者打手游。

改成中午去锻炼之后，总感觉大脑吸了很多氧，有点兴奋的感觉。

有时候早上起来感觉自己不是最佳状态，有一点点乏力，但是中午锻炼完后这种感觉就没了。

然后晚上下了班到家，基本就开始加班干活，正好也避开晚饭，干几个小时过去也不觉得饿了。

不过这不是长久之计，一份能够实现睡后收入的副业真的非常重要。

身体和习惯变化

最大的变化在肩部、胸部、后背，变平坦了很多，所以我觉得和健身有很大的关系，因为我只用这几个部分相关的器械。

只靠节食减肥的话，形体上应该不会有这么大的变化。

但是健身的话就可以改善体型，让这个重量的人看起来没这么重。

这算是个大好事吧，我觉得只要看起来瘦，那就是瘦了。瘦了就能吃点好的了。

话虽如此，吃这方面恐怕必须要永远保持健康才行了。

这一点哪怕是停止运动了也应该坚持下去。

毕竟岁月不饶人呐。

其他方面的变化没那么明显，就是整体都瘦了一圈。

说胖一起涨，说瘦也都一起没了，挺好。

早上起床以前嘴里有时候会发苦。

不知道啥时候开始完全没了

白天的话，除非晚上熬到很晚，第二天基本都不会打哈欠了。

应该是也是和精力的上升有关。

而且也没喝咖啡，本来打算喝茶来着，后来发现 700 的茶和 300 的茶简直不是一个东西。

700 的⬇️

当然也不排除老板把 100 的茶当 300 的卖，但是那个 700 的茶平时喝还是有点奢侈了，300 的茶喝起来和几十一百的没区别，口感太差，所以就不喝了。

后续计划

这次是以半年的健身卡为期，本来不想定太大的目标，先到 85kg，没想到这么快就要到了。

所以后面的四个月，会慢慢调整，直到减到 75kg。

而且现在越来越觉得，健身和游泳只是运动的一种手段，后续有了运动习惯之后，我应该会拓展到其他运动方式上。

日常记录的话，我主要是发在自己的博客动态上，写长文时再去翻一翻，回忆一下。但是目前看来利用率还是不高，只在能接触电脑的时候才能想起来记录。后面再做个 App 增加一下入口吧。

饮食和运动方面，目前来看好像可以继续保持，如果进入瓶颈期，我再进行调整吧。

一起加油吧💪

我为什么开始信任 AI 了

Sun, 17 Aug 2025 00:00:00 GMT

一开始我是不相信 AI 写的代码的。

一是我自己的原因，使用时给出的提示词过于简单，又期望它给出完美的代码，等一运行感觉相差甚远。

二是使用 AI 打破了固有的认知惯性，类似于机器批量和手工制作的区别。

这对于把写出一手漂亮、优雅代码奉为圭臬的理想主义者来说是有点难以转变的，等同于给一个合资车的拥护者推荐国产车。

但是当我让 AI 仿照我的另一个功能代码编写新的代码，并给出明确的需求以及思路后，它完成的相似度和准确度接近满分。

如果不是因为我知道我的英语水平可能起不出这种变量名，都有点分辨不出这是不是手写的。

于是我开始从某个功能，扩展到单个页面，然后再到更长更复杂的指令。

从免费的 cursor 到薅完 Kiro 的全部额度

然后再 Trae 冲了一个月会员，10 天把 600 次请求全部用完，又充了额外的 600 次请求后。

我总共使用 AI 完成了 3 个 uniapp 的微信小程序，1 个原生小程序，1 个若依的后台管理系统，1 个 uniapp 的 uts 原生安卓插件，1 个 Tauri2 + Nuxt4 的跨端 App Demo，在这一个月多月的时间内。

所以，为什么开始信任 AI 了？

因为它真的开始产生价值了。

AI 写出的代码怎么才能不跑题

Sun, 17 Aug 2025 00:00:00 GMT

最近用 AI 写了几个项目，有了一点点心得，所以来和大家分享一下，如何用 AI 写出高质量的代码，而不是写完再去返工。

想要不跑题，首先 AI 得行，因为毕竟是它来写。

我最常用的是这三个 Claude 4，kimi k2， gemini2.5-pro

Claude 是综合实力最强的，不管是解决特殊问题还是执行长任务，都完成的很出彩，但前提是它熟知了上下文，像是 Trae，对于上下文的处理明显不如 Cursor。这种情况下，编码前描述出目前的需求，再圈一两个典型页面让它去查看一下，会比直接让它写好很多。

kiro 里的 claude 是能用，但是每天会有好几次 retry，用起来不痛快。

cursor 的免费版则是不能用 claude 4

所以我现在主要是在付费使用 Trae 国际版

gemini2.5-pro 我会用于 Claude 无法解决的某个具体问题上，通常都有奇效。比如我用 Claude4 写了一个拼图、分图、长图工具，写到最后的长图功能时，claude 怎么也无法解决 bug，换成 gemini2.5-pro 梳理了一遍很快就找到了问题所在。

但它最大的问题是长任务执行不下去，我没有往深了挖掘它的用法，只察觉到它在执行长任务时会经常陷入死循环，不停的处理一个问题，而且（对于长任务）思考特别慢。

kimi k2 现在的编码能力也可圈可点，在涉及小程序这种具有国内特色的问题上，它掌握的知识库明显要比 Claude 要多一些，很好使，在处理一些短的指令时速度也很快，准确度也可以。有时候我忘记切换模型，一直用的 k2，还以为是在用 claude 。

选好大模型，确认了它的能力没有大问题，最终发出指令的还是会回到人身上

虽然现在大模型都在展示用最少的自然语言去让大模型生成一个完整的项目，这没错，可以反应出大模型到底有多强大。但现实情况下很少用到这个场景，尤其是你去接私活，而不是作为一个独立开发者。

以我目前接触的项目来说，还是要以维护和迭代老项目为主。

哪怕开了新项目，公司里的研发主导者还是会给你一个对他们来说可控的已经初始化的项目。而不是让你去 AI 自由发挥，因为代码最终是给人看的，是要维护的，虽然界面看起来可能没错，但是出了新需求就要重构或者去迭代很不熟悉的代码也是公司不能接受的。

所以第一步，就是梳理项目整体的结构。

这一步也是要AI做的，因为它整理的更快。整理的内容包含整体技术栈，主要工具类、插件、组件、hooks 在哪里存放和使用，代码风格，注释风格等。

这里其实也是可以输出设计风格的，但是 AI 很难百分百还原设计图，哪怕你把所有代码发给它。所以对于客户要求的 UI，还是要自己调整到完美状态。

AI 整理出来的 md 文档一般都带有示例，输出完毕再自己补充和纠错一下。

这一步决定了你后续的长任务准确度，限制它的过度自由发挥。

大部分 AI IDE 支持自动或手动携带这个 rule.md ，执行长任务时最好带上，尤其是你切了聊天窗口，有的编辑器就不会自动携带之前窗口的上下文了。

然后就开始下达具体需求的任务，这里其实有点考验开发者一个综合能力。

首先你需要知道这个需求具体是什么逻辑，因为 AI 提升的你的编码能力。但是如果一开始的需求就描述不清楚，任谁也做不好这个活。

这一步其实不算难，就把自己当成一个产品经理，把自己要做的东西以文字的形式描述出来就可以了。

AI 是会帮你设计架构以支持你这些需求的，甚至很多时候它设计的架构都有点过了，是咱们平时拧螺丝时压根不会去想的方向。

你同事看到这写代码只会觉得这是你从哪个开源项目上 copy 过来的，肯定不会认为是你写的。

所以此时，平时勤勤恳恳写代码，学代码，学架构的同学，此刻你的价值将会被呈数倍放大

平时的经验会告诉你这个需求应该使用什么样的架构，什么思路，你在写提示词不过是在写自己的解题思路罢了。

从怎么开始写，用什么写，用哪几个函数实现，最终实现什么，然后最后再加几个编码的注意点。然后回车，把具体功能的实现交给 AI 即可。

看着 AI 在不同文件之间实现功能，就像是看学生在做题一样，哪里错了就拒绝，这绝对不是一个非程序或者普通开发者所能具备的能力。

所以哪怕是 AI 发展的如何迅速的今天，你也不会浪费自己的努力。

但是你的老板觉得你浪费了他的钱的话，那就另说了。

毕竟 AI 对咱们开发者是考验，对老板也是考验。

有的老板愁单子不够多，AI 提效了是好事，能吃下更多单子。

有的老板只有这一亩三分地，你用 AI 节省了他一半的成本，那你就是他多余的成本。

此时，AI 写出跑题的代码都不是什么坏事了。

越乱越需要人治理。

所以，怎么写出不跑题的代码？

一个靠谱的 AI ，外加靠谱的开发，绝对不会跑题。

题外话

看到这里你可以发现，我说的这些有一个前提：针对公司项目

而你上网能看到的是什么？

纯 Vibe Coding ，xx 天完成一个 xxx

此时你看到的是对传统编码方式的无情碾压

但这其实不冲突

因为编码在这类开发者里是最不重要的一环

他们要的是最快的速度完成功能甚至不需要完成功能，就开始去大量的宣传和找到付费群体。

而公司项目开始开发时，已经是有人付钱了，所以要按付款方的标准来完成。

这已经是两种岗位、两种性格之间的差异了，毕竟销售不是谁都能做好的，机会也不是所有人都能洞察的。

所以，我想，我们可能已经在适合自己的位置上了。

Prisma 迁移到 Dizzle 后的基线问题

Fri, 15 Aug 2025 00:00:00 GMT

把 prisma 迁移到了 dizzle

由于 dizzle 的 schema 是直接让 AI 生成的，完全没看 dizzle 的官方文档

然后也遇到了已有项目迁移到 Prisma 一样的问题：设置基线。

Dizzle 也是用一个 migrations 文件夹来管理所有迁移。

初次生成时

drizzle-kit generate

生成的 sql 都是 CREATE TABLE ，这显然不应该在执行 migrate 命令时应用

dizzle 的 migrate 和 prisma 的 deploy 是一样的，就是把变更应用到当前数据库的意思

因为有 prisma 的迁移经验了，所以也能大概猜到 dizzle 也有类似设置基线的方式

于是问了一下 Kimi 就得到了答案

在 generate 命令之后，得到了一个 migrations 文件夹，以及一个 sql 文件

CREATE TABLE xxxx

拿到这个文件的 hash 部分，也就是：0000000000_xxxx_xxx

在配置文件中配置好 migrations


export default defineConfig({
  migrations: {
    prefix: 'timestamp',
    table: '__drizzle_migrations__',
    schema: 'public',
  },
})

一开始我配错了，配成了 __drizzle_migrations ，实测好像他不认这个表名，当然更可能是我不知道参数，但是我懒得去找了。

登录自己的服务器

进入数据库，如果你还没有 drizzle_migrations 这个表，可以先跑一下

drizzle-kit migrate

它会报错，但是没关系，只要帮咱创建好了表就行

然后手动插入一条记录

INSERT INTO __drizzle_migrations__ (hash, created_at)
VALUES ('0000000000_xxxx_xxx', NOW(6));

此时再去部署自己的项目时，就不会执行初始化生成的那个 sql 了，因为我们已经手动标记它已经被执行过了。

⚠️插入的这条记录注意一下，要和 _journal.json 里的值保持一致，不然后续的 migrations 都不会被执行

至此结束

你别说 kimi 给的这种方式比以前迁移 prisma 更直接，更好理解了。

prisma 的各种命令反而更绕～

周末愉快 🚀

关于Nuxt4 build 后终端没有退出的问题

Thu, 14 Aug 2025 00:00:00 GMT

最近几日，我用 Nuxt4 + Tauri2 写了一个小 Demo。

苦于不知道怎么设计 UI 时，我向 kimi 表达了我的 claude4 写不出我想要的像素风格的事儿

kimi 二话不说，给了我一套详细的方案，让我拿着去喂给 claude

然后我就成功的搞出了一套看起来像那么回事的像素风格界面

搞完后心满意足，感觉有点东西

过了几天，不忙了，寻思把我的博客也搞一搞吧。

于是我把这套规则复制过来，让 claude 继续给我在博客上重构样式

重构完了，我脑子一热，要不升一下 nuxt4 试试吧

本地环境没问题！

升完了 nuxt4，要不升一下 nuxt/content 吧

升完了也是没问题！

然后本地试了一下打包，也没发现问题

晚上回到家，换了一台电脑，发现 prisma/nuxt 有问题

第二天到了公司，我直接把 prisma 给换了，直接全部重构成了 dizzle

然后又把 pinia 给删了，用 useState + useStorage 实现

重构工作量巨大，但是一天内都搞完了

此时本地打包也没问题

但是走了一下 gitea 的 actions 发现很久都没部署完，上去一看，卡在 build 这一步了

✔ You can preview this build using node .output/server/index.mjs

走到这里其实已经完全结束了，产物也是正常的

但是就是不知道被什么挂起了，导致没有退出

我穷尽全部时间，到了下班点儿了也没找到解决方案

下班之后走在路上我脑子都晕了。

心想再也不折腾....

折腾

折腾的就是 Nuxt

很快啊，第二天就恢复了

又开始用 AI 分析问题，以及去 nuxt 相关的仓库里去找 issue

最后还真被我找到了 https://github.com/nuxt/cli/issues/169

hooks: {
    close: () => {
      // @see https://github.com/nuxt/cli/issues/169#issuecomment-1729300497
      // Workaround for https://github.com/nuxt/cli/issues/169
      process.exit(0)
    },
  },

最后在 hooks 里加了个钩子解决了

- the stall is likely triggered (but not caused) by [Nuxt Content Assets](https://github.com/davestewart/nuxt-content-assets/issues/49) (I'm the author of this module)
- however, it should be solved in the project's config

解决了，也老实了

再也不瞎折腾了 🤪

Vibe Coding 一天内完成图片编辑工具（ Trae 又行了？

Tue, 22 Jul 2025 00:00:00 GMT

最近一段时间高强度使用 Cursor、Kiro、Trae 这三大编辑器。

最开始用 Cursor，用的 fake cursor 插件，只嫖一个免费版（claude 3.5）。一用真香啊，能设置 rules，不跑题，交互也丝滑。

然而用的多了，没两天时间，感觉就不守规矩了。rules 要么就是漏下，要不就完全不遵守了。感觉是要从我手下离职，要报复我一样...🥲

自动从聊天中中总结一些临时规则虽然不错，但换了电脑好像就没了，隔一段时间好像也会自动没（？）。

这时候开始出现一些 Kiro 的宣传文章，我正好有用，就火速下载体验。

谁让他能用 Claude4 呢

体验一番后，感觉他的设计思路很不错，尤其是 Spec 模式。但我还是 Vibe 模式用的多。

也可能是 Claude4 的加持效果太好，从 3.5 到 4，像是从村里进城一样，哪哪都是好啊...

唯一的问题可能在我

这种可能是网络问题导致重试情景时常出现。

而且思考时间要比 cursor 和 trae 长很多。

由于思考时间长（可能是上下文多），还会出现死循环，不停的在解决同一个问题。

但是总体还是帮我干了很多活，准确度非常高

（但两天就被我把额度干没了）

比如我这个只用了一天时间就做出来的图片编辑工具

https://zzao.club/imgx

右键出现操作面板，支持无限分割格子

也可以分割后再把格子删掉。删掉后又可以让格子补齐它的空位。

也可以设置圆角、间距。

同时也支持直接粘贴刚刚复制的图片。

理论上可以出现任何布局

没有图片的格子就会被绘制成透明背景。

而分图功能，可以将上传的图片，分布到每个格子中。

也支持再次拆分格子，再次上传图片

如果再次切换回拼图模式，就可以再次重新给小格子上传图片

当然，再次切换到分图，就会重新把新上传的图片重新分割。

然后就是一个简单的长图功能。支持横向和纵向。

可以选完再上传图片，也支持传完再切换比例。

以上就是全部功能了（目前纯前端功能），总体用时在 8 小时以内，具体几个小时记不清了，因为我是每天写一部分。

比较关键的点就是： 要先定一个总体的架构，不管是自己写，还是让 AI 自己写，先把基本思路完全敲定。

比如我这个图片工具，核心就是维护一组数组数据，页面渲染完全依靠这组数据，调整参数就是调整数据。导出也是用数据在原生 Canvas 上重绘完全一致的页面，然后导出。

这样不管是分割格子，还是上传图片，分割图片，长图，本质都是处理这组数据。扩展性还是很高的，就算完全转为后端渲染也很轻松支持。

如果是采用了依靠 html 渲染内容，在使用 html2canvas 导出 html 内容。一是把场景限制在了浏览器上，二是需要特殊处理元素上的交互，避免导出不需要渲染的元素、辅助线等。

至于为什么做这种图片工具。

这算是我在 25 年 2 月份构思的图片工具的一部分。

一开始先做的第一部分（IMG），也就是文字生图片，还在 V2ex 发了贴，点击查看，很快就 100 多 star 了。

但可能大部分只是有兴趣，提出问题的人很少，所以我在迭代完所有内容，并且经历了一次比较大的重构。目前支持自定义模板，自定义预设，然后使用一个预设码去拿到自己想要的图片。

https://imgx.zzao.club/008/default 比如这个链接

也支持直接触发下载，点开链接即可保存图片（不过微信了不让你打开下载，会提示去浏览器

https://imgx.zzao.club/008/default?download=1

当初这个功能，吭哧吭哧做了一两个月，那时候我还是古法敲制的代码...

而图片处理这部分，一天不到就用 AI 搞完了

用 Kiro 完成了拼图和分图功能后，我正在头疼没额度了怎么办

突然 Trae 给我自动续费了。。。

此时我还在心里咒骂 Trae

本着钱都花了就试试吧的想法打开了 Trae

然后惊喜的发现它更新了 2.0 了！

并且也能和 Cursor 一样设置 .trae/rules/project_rules.md ，以前没注意它能不能设置上下文，现在才发现能设置项目的上下文，也能导入更多的上下文。

但这个 rules 仅仅就是放在这里，供它使用，你在对话中让他去操作这个 rules，自己写入，他完全不理解往哪里写，说明对话模式里没设计和 rules 的交互。

但是我也比较满意了

毕竟这么多可以用的模型，2 天内也没发现网络错误之类的问题，很稳定。

而且我只是让他不要跑出我的把控，所以有 rules 之后输出的代码就很稳定。

然后我就继续用 Trae 完成了长图功能。

非常坎坷，需求太细致了，反而不利于 AI 发挥。

但是你让它完全自由发挥，十分不可控，扩展性也比较差。正常的扩展性指的是方便支持更复杂的功能，毕竟以前需要手写。

现在对于 AI 来说，什么扩展性不扩展性的，就算重写整个项目都用不了太长时间。。

另外，SOLO模式用不了，没码！

在我畅快的使用 Trae 时，前线又传来了 Cursor 封锁中国 IP 的消息！

突然，此刻的 Trae 显得格外好用....

根本不认识什么 cursor 和 kiro ！

一个月减了7-8斤，记录饮食和运动

Mon, 21 Jul 2025 00:00:00 GMT

从6月19开始，到今天正好一个月了。记不清这是第几次立志开始减肥了，虽然之前也成功过（一次），但这次是运动量最大的，值得记录一下。

目前为止一个月时间，减了7-8斤。

先说一下我的基本情况，大概在 9 年前就胖了，而且是（大学期间）一年内快速增重。此后上班后一直没减下来。

直到工作 3 年后，从一线退居到二线城市工作，打游戏的习惯也正好断了（给我坑的退坑了！

于是卖掉了主机外设，开始减肥了。

那次减肥是我第一次大幅的体重下降，大概一个月 10 斤左右，坚持了快三个月。不过节食节的太狠了，无法再次复制。（没事，我瘦完了就正好谈恋爱+订婚了🤪）

大概保持了一年，又成功反弹回来了。👏

然后一晃又是四五年，孩子都快两岁了。又开始减肥了，抛去中间几次不成功的经历，这次我感觉成功概率非常大！

于是我决定在详细复盘一下当前减肥的过程，给大家参考一下 30 岁打工仔如何利用空闲时间锻炼，以及吃多少能稳定的掉体重。

此后也会每隔 1-2 周给大家汇报一下，以此也增强自己的信念。

运动方面

全部是游泳 + 撸铁，每天中午一个多小时时间。完事就回公司上班。

为什么不是跑步？

跑步虽然看似是个人都能跑，但是跑步姿势似乎颇有说法。大体重的人跑起来太容易腿疼膝盖疼了。而且 i 人 + 大体重 跑步，要先跑到一个心理上相对舒适，人少的场地，再开始跑，跑完就是一身汗，再回家洗澡换衣服出门，上下楼和往返时间有点长，比较容易劝退，我坚持过不到一周就放弃了。

怎么确定是游泳？

游泳我是完全自学，从零学蛙泳，平时在 B站 武装头脑，然后下水实战。

我先办了一个 10 日体验卡，每天找人少的时间点去练习，先漂浮、站立、换气，这三步下来，我在第三次去游泳，已经在练蛙泳动作了。

也就是可以下水，然后漂，蛙泳，游到 10 来米的地方，站立，转身，再游回去。

前期从什么也不会到能在水里前进，正反馈是很强的，所以我觉得我适合游泳。

而且游泳在水里不累，出来才感觉很累，出来也没有汗，干干净净的就走了，很惬意。

所以一开始我笃定自己主攻游泳，健身辅助一下。

除了周二泳池维护，有两次周末全家出去玩，连吃两天。其他时间全勤！

办十日卡那次只是十来米一停，心率一点上不去，就和玩水一样。

现在能去深水区之后，25米一趟，还要再回来，直接累的不行。每个来回都要休息+调整泳镜，泳镜有一点进水就非常难受了，总担心它进水，感觉进了水我就要死在泳池里。

尝试了两周之后（游泳每次 40 - 60 分钟（指在水里的时间）），发现完全没有厌烦的情绪，于是买了佳明255（能坚持再买）。（前两周撸铁次数不连续，第一天就给我肩膀头子干疼了，休息了两天再去）

不幸的是买完手表大腿根就开始疼了（腿部发力问题），没法游泳了，中断了一周时间，这一周只撸铁。

大腿根疼，就是因为动作不对，发力点错误，去医院看了一下，是髋关节附近有肌肉组织水肿，也可能有炎症，给开了两个药，吃了两天就感觉好了。然后又痒痒了，没忍住又去游了一次，出来又疼死了，不过幸好这次没持续，隔天就没事了

游泳暂停的这一周（也就是第三周），每天保持撸铁。

先说一下如何克服第一次去健身房的问题。

我第一次去健身区，很尴尬。一拐弯进去好几个人同时看我，我装模作样往里面打探了几眼，转身出来了....

然后第二天去，没人，赶紧去固定器械区域摆弄摆弄，看看咋使。

第三天去，直奔会用的那两个器械。

第四天往后基本就没感觉了。每天健身的固定就是那些人，偶尔周末来的人多一点。

所以，i 人第一次还是选个十分蹊跷的时间去吧！

撸铁第一周我用的 40 斤，只练胸部、肩膀、背部。目前能叫上名的就是蝴蝶机，其他的不知道，也不太关心，但是已经固定每天用这几个器械了。

每次去，12 - 15 个 一组，一次大概在 12-16 组左右。

只知道别耸肩，哪里发力的也不清楚。

直到第四周，用蝴蝶机时才明显感觉到胸部上方和肩膀头子链接这一片肌肉有发力感和胀胀的感觉。

还有个坐着往前推的练胸的器械，推不大动，所以用的少。

还有个坐着往后拉的，练背的器械，我用的是最多的。

练胸的可能我只做 6 组，但是练背的这个我得拉 10 组或者 12 组，感觉拉着有点舒服。

第一周是 40 斤，第二三周基本都是 50 斤，第四周练胸的还是 50 斤，练背的用 60 斤。到目前是第五周，其他还是 50 斤，练背的用 70 斤....

这些就是在健身区的锻炼情况。由于强度太低，时间太短。我每天练完，不管是晚上还是第二天，都没有明显的感觉。偶尔刚开始拉的时候感觉有一些昨天训练导致的疼痛，但啥也不影响！

因为我只是为了一个健康的生活习惯和持续的减肥，不是为了练大练强。

健身在我目前看来还是有点无趣的，没有技巧，纯粹的消耗。而游泳充满技巧，是一个可以长期投入的运动。

第四周，我的腿已经好了！并且给自己安排了新泳镜！有了手表我也想知道自己的配速如何🤔

在简单学习了如何转身之后，我开始持续的游 100 米或者 50 米。（没错，我在第四周才可以不停下来整备，以前都是游到头就手动转身，然后反复多吸几口气再出发。）

新泳镜让我非常放松，因为我知道它不进水。其实第一天连雾都不起，从第二次开始就起雾了...

回想起之前在泳池里，12 米一停，25 米一停，现在感觉持续 100 米还真挺累。而且只有（相对）持续时间长了对有氧运动才会产生积极影响。

有了之前腿疼的惨痛经历，这一周我时刻提醒自己收腿和蹬腿的正确性，不要打开太多髋部。在水中漂浮时间也适当延长 1s。手部动作虽然不提供多少动力，但是做不对是挺影响速度的，尽量标准一些。整体游泳时间也控制的短一些。

对游泳来说，除了第一周感觉到自己进步了，中间两周时间都是挫败感，直到第四周纠正动作才开始感觉到走水效率提高了。还是要慢慢奔着长游去，速度慢一点无所谓了。

目前是第五周第一天，今天的运动时间还是和往常一样。

12 点 10 分左右，到了健身房先换衣服，去撸铁，今天撸了 13 组，一看表 12 点 45 了，就必须去游泳了，不然时间不够。

淋浴

然后先游了一个 250 米（肯定给我记错了，一个来回是 50米），再来了一个 100 米（配速 2 分 55），然后剩下时间就是在练自由泳打腿

13 点 15 分，必须去洗澡然后返回公司了。

公司楼下吃个饭，然后上楼（14:00）。

以上就是每天的时间安排。

饮食问题

这次的饮食重点就是不能太节食，节食减下来，还是要吃回去，因为不可能永远不正常吃饭啊！

所以先改结构和量

首先糖类是一点不碰了，零食、饮料这种是完全不喝的。

早饭基本还是正常买着吃，以前小笼包要吃一笼，现在改成半笼+鸡蛋/豆浆。

中午饭怎么也得吃，上次减肥就是中午也吃草，后面完全不行，还要都补回来。

这次中午就是不那么忌讳碳水，但油太大的先 pass 了。

板面+鸡蛋+鸡腿+豆干，这种套餐吃了好几次。

兰州拉面+煎蛋吃了两次。

水饺，茴香肉、芹菜肉这种，吃了好几次。

沙县的鸡腿、鸭腿套餐吃几次。

麻辣烫，素菜为主+手擀面+丸子，吃过一次。

工作日基本就是只有这些选择。

只吃草肯定是不行的，因为我是中午先运动再吃饭，顶不住的。

如果更狠一点，全换成减脂餐，估计能瘦更多。但是我宁愿慢一点，也要平滑过渡。

水果吃的也比较少，偶尔会吃个火龙果，主要是为了拉屎问题。因为吃的少，没油水，蔬菜也少，很容易便秘。

这个月的周末基本都有活动，不是去旅游，就去回老家，就算在家也要带孩子去商场，所以基本控制不住，一天最少放纵一顿（一共两顿）。

放纵完之后，周一体重基本要回升 1-2 斤。（称体重时间为每天早上空腹）

吃的少的话，周二就开始缓慢下降。吃的多要到周三到周四才开始下降。

只有第四个周末，也就是上周末。同样是去结婚吃席，但是我没吃米面，只吃牛肉、羊肉、排骨（甜的偷吃了一个炸地瓜丸子），也感觉吃了不少，有七八分饱。

到周一体重还是往下降了（0.5kg）！

饮食问题需要根据自己身体情况调节一下，反正我是开始控制饮食之后，拉屎不通畅了，非常伤心。

目前复盘一下主要发现的问题，蔬菜太少，水果也太少，蛋白质好像也不多。

后面早上可以考虑在家磨个五谷豆浆，啃个玉米，吃个鸡蛋。

中午在公司条件有限，很少有吃大量蔬菜的机会，这个跳过吧。在家带一把坚果，增加一下优质脂肪？

晚上继续少吃或不吃吧，目前没感觉有啥问题（再减 10 斤左右观察一下）。

热量消耗

从有手表后开始统计。

每天运动消耗平均 572，平均总消耗 2866，平均静息 2294

（我以为运动消耗能有多少呢，没想到这么点）

睡眠质量：高 ，得分 80+，时长 7-8 小时左右。

按上面的方式吃的话，肯定是有热量缺口了，不然也不能瘦下来。

效率提升的可能

游泳这块，第一个月也就是玩玩水，强度太低，休息时间太多。

从这周开始长游时间变长，应该可以在同样时间内可以消耗更多的能量（？）。

健身这块，再看感觉加加重量？我怕效果太差，感觉增加一点健身房锻炼时间也可以。

运动方面的提升方向看起来不大，就是靠体能的上升，自然而然的提高代谢。

还是要在吃的上面下下功夫。

先把早饭安排的更健康一些，把面食去掉。

午饭随缘，看心情吧，上班为主，没啥操作空间。

晚饭已经不咋吃了。

周末在家的话，要重新抓起自己的厨师身份，安排一些肉类食品。在外面的话，吃的仔细一点。

最后

选择什么运动感觉还挺关键的，如果自己都排斥，那几乎是不能长期坚持的。

有搭子应该会更好，动力更强一些，毕竟有人交流。

然后在自己喜欢的方向上投入一些金钱，也会更加愉悦一些。

最终目的不是减到多少斤，是让日常的习惯发生根本的改变。

减肥可能只是其中一个最小的好处～

下周见啦😎

交互效果太单调？推荐两个动画丝滑的组件库，Vue 和 Nuxt都适用！

Fri, 11 Jul 2025 00:00:00 GMT

对于开发人员来说，最头疼的问题可能就是如何让自己的界面变得又高级又简洁、又丝滑又不拖泥带水、又有趣又不繁杂....

这也是我非常头疼的且至今都解决不了的问题！或许最好的办法就是专业的事情找专业的人去做！去找设计师！

开发、设计、销售，总不能一个人全占了吧（那你也太牛了吧！

虽然做不到尽善尽美，但是我们可以借助 UI 库来实现相对简洁、高级、丝滑。

对于简洁来说，shadcn/vue 是我的首选，因为它的生态最完整，不仅仅是基础组件，还包含了一些好用的第三方组件。

对于动画效果，我推荐这两个专门针对动画效果的 Vue 生态下的库

inspira-ui 、vue-bits

inspira-ui

官方地址：https://inspira-ui.com/

Github：

star: 3.4k
MIT

完全兼容 Nuxt 和 Vue

组件统计（108 个）

类型	个数	说明
Backgrounds	20	背景
Buttons	5	按钮
Cards	6	卡片
Cursors	2	鼠标悬浮效果
Device Mocks	2	模拟 iphone 界面，会加载 url 实际内容
Input And Forms	3	表单
Miscellaneous	25	一些特定的场景的动画效果
Special Effects	10	特殊动画效果
Text Animations	22	文字动画效果
Visualization	13	3D效果

部分效果图

注意：大部分都是带动画的，此处只是演示静态图

special effects

backgrounds

buttons

Cards 3D Effect

Lens

收费组件

地址： https://pro.inspira-ui.com/

一开始这个库是没有收费组件的，全部免费，现在多出了几个收费组件（inspira-ui Pro）。

Inspira UI Pro Component Pack 2 @ $25
Inspira UI Pro Components Pack @ $15
Inspiria - SaaS Landing Page Template @ $49

前两个是一些拥有特殊的交互效果的组件，第三个是模板

吐槽一下：我喜欢交互丝滑的动效，但很多组件动画过于复杂，已经影响了实用性，可能只适合于炫技。

依赖情况

组件不同程度的依赖了以下几个库

gsap
tailwindcss v4
threejs
motion-v
@vueuse/core

集成到项目

同 shadcn/vue 的集成项目，门槛很低。

支持复制粘贴使用
支持 Inspira 的 Cli 工具安装

vue-bits

官方地址：https://vue-bits.dev/

Github：

star: 296
MIT

完全兼容 Nuxt 和 Vue

虽然这个库看起来 star 很少，但它和 react-bits 是同一个作者，react-bits 的 star 是 18.4k

组件统计（69 个）

类型	个数	说明
Text Animations	19	文字动画效果
Animations	16	动画效果，可以包裹子组件
Components	17	常用的组件，如轮播图、瀑布流、相册
Backgrounds	17	动态背景效果

部分效果图

components

text animations

Pixel Transition

Click Spark

Stack

收费组件

无

依赖情况

后两个库主要是支持 Backgrounds 这一类别的动画效果

gsap
motion-v
ogl
three
postprocessing

集成到项目

同 shadcn/vue 的集成项目，门槛很低。

支持复制粘贴直接使用
支持 Cli

总结

组件数量上 Inspira 胜过 Vue Bits 一头

但 Inspira 的分类的命名非常不清晰，让人眼花缭乱，容易劝退。 Vue Bits 可以清晰快速的找到自己想要的组件。

依赖情况上是差不的，但还是因为分类原因。Vue Bits 显得更加清晰一些，如果不用 Backgrounds，那绝大部分只需要 gsap 和 motion-v，极个别需要 ogl

集成到项目中同样轻松！

不知道是否是文档页面风格的原因，Vue Bits 给我的感觉更加简洁和克制，Inspira 更加花哨。

把组件整体浏览下来也感觉 Vue Bits 似乎可用的组件更多一些（虽然总体数量更少）

不知道你怎么看？

以上就是两个组件库的整体情况了！

不得不说，有了 Nuxt 对 Vue 的包装，大大提升了开发体验。基础组件库又有 shadcn 这样全面的选手。再加上 Vue Bits 或者 Inspira 这种针对于动画效果的组件库。

再也不用担心页面过于粗糙啦！

欢迎访问我的个人博客，里面有更多 Nuxt 最新实战内容 🙌 🙌 🙌

Vercel 收购 NuxtLabs！Nuxt UI Pro 即将免费！

Wed, 09 Jul 2025 00:00:00 GMT

Vercel 收购了 Nuxt 以及背后的核心团队 NuxtLabs !

此时，Vercel 已经同时拥有了 Next 和 Nuxt 两个分别由 React 和 Vue 发展而来的服务端渲染方案！

（ Nuxt 官方是不是不用再卖课挣钱了😂

收到消息后，刷新了一下 Nuxt 的官方，发现已经置顶了一条消息！

NuxtLabs is joining Vercel

消息的大概内容为：

虽然被收购了，但是还是会专注于 Nuxt 和 Nitro 的开发，继续遵循 MIT 协议

感谢xxx，感谢 xxx，感谢 xxx

还有三个接下来要发生的重要消息：

发布 Nuxt UI v4，其中 Nuxt UI Pro 组件以及 Figma Kit 将免费提供给所有人（这就是金钱的力量吗）
开源 Nuxt Studio 的自托管版本（我的博客要退休了？）
NuxtHub 独立于其他提供商支持（Make NuxtHub agnostic to support other providers, integrating with Vercel’s Marketplace offerings like Postgres and Redis will become seamless.）

看到 NuxtLabs 终于找到了金主爸爸，我作为深度使用 Nuxt 生态的一员，也是由衷的开心啊

（有了钱，就不用把一个开源项目掰成两半去卖了！

虽然平时大部分前端接触的是 Nuxt，并且仅仅是用作 SSR，但支持 Nuxt 的 Nitro 实际上也非常简单易用。搭配 Nuxt ，而不用再去使用 NestJS 来写后端。

不仅是 Nitro，Nitro 使用的（基础库） H3，以及 unjs 这个组织下的很多包都非常好用。

比如我在所有项目内使用的 unjs/changelogen 用来自动生成 CHANGELOG.md，同时发布新版本和推送到 Github

再比如 NuxtImage 默认使用的 unjs/IPX，可以非常简单的搭建一个图片服务，并且支持你使用一个 URL 就能拥有 sharp 的大部分功能来直接转换图片格式、压缩、裁切等

再比如开发命令行工具用到的 unjs/consola 等等等等

🤩🤩🤩

希望 Nuxt 越来越好～～

话说有钱了，能不能把官方卖几百刀的课程也免费一下 😃

Vue 官方 VSCode 插件发布 3.0 大版本，更好用！更智能！

Thu, 03 Jul 2025 00:00:00 GMT

Vue (Official) 在近日发布了 V3.0.0 大版本更新，我也是在第二时间进行了更新，发现有一些好用的新功能值得一说！

组件引入新方式

现在引入 vue component 可以直接从一侧的文件栏拖拽到 template 标签中。

拖拽后按住 shift 键，会在当前鼠标位置生成一个组件标签，并且在 script 中自动引入改成组件

组件 props 提示

现在使用某个组件时，会直接提示你必传的 props，不用再去组件里找了！

组件点击直接跳转到组件本身

在 template 中点击某个组件，现在会直接跳转到组件文件，而不是 tsconfig 的定义处了！

Props 提示

众所周知，vue3.5 之后（没记错的话）,defindProps 可以直接解构了。

// const props = defineProps<{ id?: string }>()
const { id = '标题' } = defineProps<{ id?: string }>()

假如继续写一个其他的 computed 或者 watch 时，用到这个 id，显示会有一个提示。

告知你这个 id 来自于 props

.value自动补全

当使用一个 ref 变量时，现在会自动补全 .value

设置里需要勾选

结语

以上就是我发现的一些新功能，如果有所遗漏，欢迎评论区补充～～

集市周报 Vol.05

Thu, 26 Jun 2025 00:00:00 GMT

这两周是游泳的两周！所以这次是一个记录锻炼和身体变化的报告！

前言

25 年 3 月份，办了一张游泳健身十日体验卡

满打满算，游了七次，一次 40-60 分钟

前两次练习漂浮+站立+换气，然后随便练一下蛙泳动作。

第三次发现可以走水了。开始尝试在浅水区游

第四次，可以泳 25 米了，但是不敢停，因为不会踩水。

果然，不出意外的出意外了。

第4 还是 5 次在深水区泳镜进水，对于在水里睁不开眼的新手的来说，直接在水里停下来了，而此时还不会踩水。幸好水不是特别深，触底蹬一下，勉强摸到池边，扒拉着回浅水区了。自此就不敢去深水区了。

后面两次，感觉不到任何进步了，而且泳镜开始时不时进水，搞不懂为什么。只能在浅水区来回游动。

看视频在脑子里记得理论挺多，下了水感觉感受不到自己的肢体在哪里，也不知道如何改进。看别人在岸上拍的视频，发现确实动作非常拉跨。

但是十日卡到期了，就此告一段落。

再入半年卡！

25/6/18 再次入了半年卡。

当日，周二，请了半天年假（去年的年假，快到期了），前往健身房游泳。

去了之后发现忘记了周二泳池维护！！第一天就出勤失败了☹️

次日开始至今，已经坚持两周。

目前 14 天，去了 11 天，一天是泳池维护，两天是周末回老家。

锻炼日常

去健身房一般是空腹，喝点电解质水，别太渴就行。

先去游泳，40-70 分钟。视情况而定，有时候腿疼，只能游 30 分钟

前七八次是不能泳完整的，要么到中间就停下掉头，不敢去深水区。要不到头就要停下来，泳镜进水也很致命...

就是不停的练习，感受身体怎么走水。再回想一下白天看的视频教学，实践一下。

最近的三四次已经可以完整游几个来回了，但是离一口气游 500 米、一千米还差得远。

不过也是好事，仅仅是游游停停，身体的消耗就足以稳定的让体重下降。随着技术和体能的提升，游一次消耗的会更多，不会出现瓶颈期。

游完再去撸铁。

只用固定器械，而且也练的比较随意。

一开始不会用，进去也比较尴尬！幸好健身房没啥人，第一次去先自己摸索几个器械，看看器械上的示意图，看看是练哪里的。

后面去就不咋尴尬了！去的时候玩着手机进去，就像经常来一样，把包随手一扔！😃

目前只练胸、肩、背这几块。腹部肥肉太多，感觉会很容易出汗，而且每个器械都要收紧腹部（应该也有用吧）。不练腿，因为我要留着蛙泳，蛙泳蹬腿蹬不对也容易大腿根疼，所以不适合再上强度了。

这一套下来，总共耗时 90 分钟左右。

身体变化

这两周，体重少说掉了 5 斤

更明显的是体态的变化，肩膀打开了很多，之前有些肱骨前移，应该是长期敲代码导致的，背部肌肉激活后，感觉给拉回去了。

腹部底蕴深厚，暂时没感觉到有变化！

腿部也不是很明显。因为我属于哪里都有点肉，整体得有 30% 的体脂率，瘦也一起瘦，胖也一起胖，所以感觉上不明显。

再说精神头！

白天精力比较充沛，不会犯困了！运动应该有一定的作用！

还有个原因，以前晚上喜欢熬夜玩手机，高低得玩到 12 点，无法停止。但是现在要陪孩子睡觉，孩子他妈讲故事，孩子睡觉也很慢，大人不可能还在一边玩手机！有几次我都想着等他睡着再起来看一会小说，但是他实在睡得太慢，听故事听的我都困了，就睡着了...

早上八点起床，还是比较晚，因为我九点半到公司就可以。后续应该是调整到 7 点左右，早上再干点事做。

穿戴设备

因为感觉锻炼节奏趋于稳定了，所以想买一个手表来记录一下数据。

首先非常确定不会买超过 1000 价位的表，以此为基础做了一点点功课。

迪卡侬w500

价格很便宜，119 元

装电子的，续航两年！

能看时间，计时全靠手动。

如果比较纯粹的运动者，感觉还挺合适。

华为手环 10

价格也便宜，标准版 177 元，NFC版 220 元。

我在多个平台搜运动手表，或者游泳手表，推荐华为手环的是大多数。

都说记录的比较准确！和小米手环形成了强烈对比...

防水也够用

很心动这个来着，便宜，能用。

但是我又知道了佳明这个牌子...

佳明 255

价格，1173 元（有国补），以往价格似乎能到 2400+ ，这价掉的真狠啊。

佳明的数据记录的多，运动种类多，续航也长

虽然在不同平台很多人表示游泳数据不准确，但是我还是挺心动。

因为我估计不会死磕一个运动项目，在体重降下去，体能上来之后，其他运动也都会去尝试。

而且普遍都说佳明比较专业，所以最后还是说服了自己。

不过最后也没买新的。闲鱼自己找了个 850 元的下手了

后续用起来也会写写体验如何。

最后

最近的目标还挺明确的，就是锻炼。拉长战线，半年为期，扎扎实实的提升。

希望在儿子上学之前瘦下来！

然后和他一起去尝试、去玩各种好玩的运动 🛹 ⛸️ ！

Nuxt 3.17 发布，对比3.16有一个重大改变

Tue, 24 Jun 2025 16:04:08 GMT

今天逛 Github ，发现 Nuxt 又发新版了： 3.17.0

更新日志

数据获取改进

数据一致性：所有使用相同键的 useAsyncData 或 useFetch 调用现在共享底层引用，确保应用中数据状态一致。
响应式键：支持使用计算引用、普通引用或 getter 函数作为键，当键值变化时会自动触发数据重新获取。
优化数据重新获取：多个组件监听同一数据源时，依赖项变化只会触发一次数据获取。

新增内置组件

<NuxtTime>：用于安全显示时间的组件，解决了在服务器端渲染和客户端渲染中处理日期时的水合不匹配问题，支持多种时间格式。
<NuxtErrorBoundary>：转换为单文件组件，暴露 error 和 clearError，便于在模板中处理错误。

路由改进

<NuxtLink> 新增 trailingSlash 属性，用于控制 URL 格式，添加尾部斜杠。

加载指示器自定义

新增 hideDelay 和 resetDelay 属性，用于控制加载指示器的隐藏延迟和重置延迟。

文档作为包

Nuxt 文档现可作为 npm 包 @nuxt/docs 安装，提供构建文档网站的原始 Markdown 和 YAML 内容。

开发体验改进

新增多个警告，帮助开发者避免常见错误，例如：
- 服务器组件缺少根元素时发出警告。
- 使用保留的 runtimeConfig.app 命名空间时发出警告。
- 核心自动导入预设被覆盖时发出警告。
- 同一文件中多次使用 definePageMeta 时发出错误提示。

模块开发增强

新增 experimental.enforceModuleCompatibility，允许 Nuxt 在加载不兼容模块时抛出错误。
新增 addComponentExports，可自动注册文件中通过命名导出的组件。

性能改进

使用 tinyglobby 提升文件 glob 操作速度。
排除 .data 目录的类型检查，加快构建速度。
通过提升 purgeCachedData 检查来优化树摇优化。

其他改进

提供升级命令 npx nuxi@latest upgrade --dedupe，用于刷新锁文件并拉取最新依赖。
修复了多个问题，包括错误处理、路由解析、类型检查等。
文档更新，包括对自动导入、SEO 等内容的改进。
测试和 CI 流程的改进。

主要影响点

useAsyncData、useFetch

以前写 watch 时，每次 watch 的值发生改变，回调函数会再次执行一次。

现在不会了！

// In multiple components:
const { data } = useAsyncData(
  'users', 
  () => $fetch(`/api/users?page=${route.query.page}`),
  { watch: [() => route.query.page] }
)

// When route.query.page changes, only one fetch operation will occur
// All components using this key will update simultaneously

取而代之的是增加了一个响应式键

可以直接用 computed 作为键，里面的响应式对象发生改变时，回调函数会再次执行

const userId = ref('123')
const { data: user } = useAsyncData(
  computed(() => `user-${userId.value}`),
  () => fetchUser(userId.value)
)

// Changing the userId will automatically trigger a new data fetch
// and clean up the old data if no other components are using it
userId.value = '456'

这也是对我的博客站有影响的一点。之前文章页的几个 tab 切换靠的是 watch

不过依然没让我失望，升级之后火速发现了奇怪的bug。

然后又从 3.17 退回了3.16.2。。。

2025年05月06日09:33:34 更新

五一结束了，nuxt 更到了3.17.2，解决了客户端组件 useAsyncData 的问题

本地升级后，在 useAsyncData 里使用 响应式key，看起来表现正常了

之前说好的 3.11 是最后一个小版本，现在愣是发到了 3.17

虽然实际上更新的内容已经在向 Nuxt4 过渡，但是不知道为什么 Nitro 为什么不发 3.0 (之前提到不发4.0是因为Nitro不发3.0)

Nuxt 全栈开发·自定义响应和全局错误处理

Tue, 24 Jun 2025 00:00:00 GMT

使用 Nuxt 全栈开发时，如何像 NestJS 一样优雅的设置统一的响应体，以及如何捕获全局 Error

自定义 Handler

官方文档

import type { EventHandler, EventHandlerRequest } from 'h3'

export const defineWrappedResponseHandler = <T extends EventHandlerRequest, D> (
  handler: EventHandler<T, D>
): EventHandler<T, D> =>
  defineEventHandler<T>(async event => {
    try {
      // 拿到接口文件里返回的响应值
      const response = await handler(event)
      // 自定义统一的结构
      // 自定义code，自定义 message
      return { code: 200, data: response, message: 'ok' }
    } catch (err) {
      // 自定义错误响应体
      return { code: 500, message: 'error' + err }
      // 或直接抛出错误
	  // throw createError({
      //  statusCode: 500,
      //  message: '出错啦，请稍后再试～',
      //})
    }
  })

使用时将 defineEventHandler 替换为 defineWrappedResponseHandler ，同时直接 return data 。

export default defineWrappedResponseHandler(async (event) => {
  const schema = z.object({
    id: z.string(),
    user_id: z.string().optional(),
  })
  const query = await useSafeValidatedQuery(event, schema)

  if (!query.success) {
    throw createError({
      statusCode: 400,
      statusMessage: (query as any).message ?? '参数错误',
    })
  }

  // 伪代码
  const data =  await prisma.findMany()
  
  return data
})

在 plugins 中使用 hook

官方文档

nitro 中有多个生命周期钩子可供自定义，可自行设置标准响应体，打印日志等

export default defineNitroPlugin((nitroApp) => {
  nitroApp.hooks.hook("request", (event) => {
    console.log("on request", event.path);
  });

  nitroApp.hooks.hook("beforeResponse", (event, { body }) => {
    console.log("on response", event.path, { body });
  });

  nitroApp.hooks.hook("afterResponse", (event, { body }) => {
    console.log("on after response", event.path, { body });
  });
});

使用 beforeResponse 实现自定义响应体

export default defineNitroPlugin((nitroApp) => {
  nitroApp.hooks.hook("beforeResponse", (event, { body }) => {
    if (t?.body) {
	    t.body = {
		    code: 200,
		    data: t.body,
		    message: 'ok'
	    }
    }
  });
});

以上就是两种设置统一响应体的方式

errorHandler

官方文档

Path to a custom runtime error handler. Replacing nitro's built-in error page. The error handler is given an H3Error and H3Event. If the handler returns a promise it is awaited. The handler is expected to send a response of its own. Below is an example where a plain-text response is returned using h3's functions.

nitro 中有一个默认的错误页面，你可以自定义自己的 errorHandler 用来和统一响应体

export default defineNuxtConfig({
	future: {
	    compatibilityVersion: 4,
	},
	nitro: {
		errorHandler: '~~/server/error'
	}
})

export default defineNitroErrorHandler((error, event) => {
  setResponseHeader(event, 'Content-Type', 'application/json')
  console.log(`[${new Date().toLocaleDateString()}]-[nitro error]: `, error)
  return send(event, { data: null, message: '服务器异常' })
})

以上就是群里小伙伴们各自实践中得到的经验！

希望对你有所帮助☺️

无需额外软件，MacOS 缩小托盘图标间隔

Fri, 13 Jun 2025 21:22:13 GMT

众所周知，macos 有些机型的刘海屏十分反人类，导致图标展示不全。

此方法可以无需软件缩小图标的间距

原贴地址 V2ex

# 指定间距  
defaults -currentHost write -globalDomain NSStatusItemSpacing -int 5  
# 指定内边距  
defaults -currentHost write -globalDomain NSStatusItemSelectionPadding -int 5  
# 当前间距查询  
defaults -currentHost read -globalDomain NSStatusItemSpacing  
defaults -currentHost read -globalDomain NSStatusItemSelectionPadding  
# 重置  
defaults -currentHost delete -globalDomain NSStatusItemSpacing  
defaults -currentHost delete -globalDomain NSStatusItemSelectionPadding

集市周报 Vol.04

Mon, 09 Jun 2025 00:00:00 GMT

没事真别生孩子

真的。

虽然孩子在能听话、能懂事、能提供情绪价值、甚至老一辈老说的有人给你养老这一条也算上，这些幸福时刻都加在一起，也抵不上自己要付出的时间、精力、体力、心力。

说白了，确实是太穷，没法和富人家一样富养。

但也没法和揭不开锅的家里一样放养。

因为最基本的责任感还没有被泯灭，心里还是希望孩子能以相对正确和个性鲜明的认识这个世界。

尤其是你还要处理那些不知道就会被优化掉的工作，原本就不怎么和谐的原生家庭，稍不注意就会被反复质问的新家庭。

我是一个对陌生人以及对我比较友善的人会更加有耐心的人，也架不住孩子的折腾。

包括我的同学朋友们，刚有了娃之后，没有一个不叫苦的。

运气好的一岁以内可能就睡上整觉了，运气不好的，要到一岁半左右了。

能睡整觉了，意味着白天精力旺盛。

时走路时抱着，安全感也比较差，一个人带娃就全程挂在脖子上。

好在什么呢，能看电视，能看手机了，只要看上动画片就能安静。

但是你希望他一直看电视吗？从小就刷抖音？

就一个孩子就这么多事，还是孩子比较听话，比较有专注力的情况下。

我真不明白那些以前生那么多的，还有生俩生仨的咋管的孩子😷。

不过可以肯定的是，如果你没什么责任感，放着不管孩子一样可以长大。毕竟家里不止两个人，你不上心，自然有其他操心的人订上。

你说你就是放不下孩子怎么办。

呵呵，那就是操心操死的命。

疯言疯语

怎么才算是比较舒服的环境？

第一，请保姆。

把最麻烦的、最操心的事交给保姆。你自己一边记录一边享受一个干干净净且高高兴兴的宝宝。

这样，没有婆媳矛盾，谁也别操这心。做饭不好吃，直接反馈给保姆，毕竟是自己花钱请的，提出问题来不需要有所保留。

这样孩子每天生活习惯固定，吃的营养，有充足的外出时间。

第二，抛弃道德。

作为一个 30 岁的人，最重要的还是要搞钱，被别的事情耽误的了时间，你别想翻身了。
家里的事，没有什么是必须谁做的，必要的时候要立即放弃自己的道德感、负罪感。
如果可能的话，用钱来修补感情，比心要好使。

第三，完全放弃同化家人。

父母已经 50+，从根本上不能完全理解另一个时代出生的人的生活习惯、思维，想和父母掰扯清楚完全不现实，如果他们可以被改变，那早就已经自己想通了，轮不到你来苦口婆心。
每个人都是一个独立的个体，一个独立的个体要有自己的生活规律，要有自己的规划，要有自己的处事逻辑、待人逻辑。父母拎不清，没有从小教育，只能自己多吃点教训才能长记性了。
相伴一生的爱人，指的是两个独立的个体，在某些方面存在共鸣。两个尚未开化的人走在一起会轻易的被琐事绊脚，以后也只能做暴富的梦，生活质量全看上一辈人够不够啃了。

以上

疯子的话完全不可信。

我被折磨疯了，所以我上面的话完全不可信。

集市周报 Vol.03

Tue, 03 Jun 2025 00:00:00 GMT

高速上快速路跑 90 的，你他妈真该死啊！

博客

上周主要是给博客上加了个注解的功能，因为在别人的博客里看到了这个功能。

微信公众号的文章上也有类似的功能，不过是可以划线评论。

于是我也在自己的博客上加了个这种效果，划词之后添加内容。目前先限制只能我自己来写，因为做着做着发现评论的多了不是啥好事，看起来很乱。但是这个功能已经是有了，无非是把权限判断逻辑改一下的问题，后面应该会在写游记、攻略类的文章上用上这个功能，方便读者就某一步、某个地点、某笔消费进行讨论。

选中交互

输入弹窗

hover 效果

伤员 1 号

济南的路多是起起伏伏的。

可能是因为东部就是靠炸山、填平等操作来开荒的。

所以济南东边一般骑不了太长距离的共享单车，打工仔主要交通工具就是电动车。

这不，我表弟刚来济南工作第二周，骑着个电驴在下坡路上被打右转向灯的车个吓了一跳，一刹车飞出去了，直接扎到了护栏那个钢管上。然后被一个路过的好心大姨送到了最近的医院里去，当时他还不知道自己的脾可能裂了。打电话通知我的时候已经做了彩超之类的，疑似脾破裂，严重的话可能要切除。

前几天就是一直输液，一动不能动，到了周五下班后我就去陪床了。

这是个老医院了，从建筑到设施都让我怀疑要不就是真不赚钱，干的就是菩萨的活，要不就是有史密斯专员搞鬼了。我大学的系楼虽然也不买啥新设备，好歹还年年刷刷漆。

早上医生查房，问医生怎么弄，医生说：观察，观察一周。我说行，然后医生就走了。此时我还没意识到问题的严重性：直到第二天早上这个医生查房，你就再也找不到能提供指导的医生了。

整层住院的病房，不知道有几个医生值班，应该不超过 2 个，一楼还有急救室，有时医生会去做手术。

而且我没有住院经验，不知道医生和护士的职责划分就和互联网企业里的开发和产品一样严格，护士只能按医生开的单子（医嘱？）进行换药，其他的工作主要是叮嘱以及帮忙护理。护理不合格，还要扣绩效或者罚款之类的，也难怪护士们根本好脾气不起来（胖东来的含金量还在提升）。所以，只要医生一撤退，护士对这种身上插着管子的病人，哪怕再有困难也只能等到明天。当然了，除非家属极力要求，他们还是会直接给医生打电话，寻求下一步的指示。

而且护士的数量也堪忧，大概是十个产品经理对一个全栈开发的水平。

就这样，他腿上的纱布，硬是顶了 6 天，然后让一个实习值班医生（研究生）给揭下来了，因为护士不能换，医生轻易找不到人，找到后需要先问出血的脾脏怎么办，所以只能先把腿放在一边了。

终于去做腹腔穿刺了。这也是我第一次直接目睹小手术的全过程，差点给我干吐出来。这个大夫表示怎么这么晚才来做穿刺，淤血都比较粘稠了。此时我脑子里只有两个字：观察。当晚出了 700ml 的淤血，然后这个袋子就需要一直挂两天。后续没有继续出血，表示止住了，等拔了管之后复查一下可以安排出院。

然后你懂得，又是艰难的等医生到次日早上查房。

我没等到他拔管办出院这一天，因为我丈母娘也摔着了，住院了。

伤员 2 号

大于 55 岁的人，再伤着骨头就比较难养了。

去之前我们还以为挺严重的，第二天一早就驱车前往当地的县医院。不过幸好不需要手术，但尾椎和腰椎各有一处骨裂（？）之类的，最起码先观察一周，然后最少躺一个半月。

本来我对象已经做好了在那边陪床的准备，听家里人描述，是在楼梯上一节一节的出溜下来了，看起来是不需要在那边守着了。那就等下周末再过去一趟。顺便给小舅子的新家里买个床和冰箱，估计丈母娘出院之后还是先在楼上静养一个月，有冰箱比较方便一些。小县城，又是新房区，附近几里地内没大有餐馆，也没找到可以送饭的。所以还是自己备一些预制主食，再穿插点几天外卖。

来去匆匆

还没从前两天的陪床中缓过来，又一天开了快六个小时的车，导致我晚上做梦都是在开车...

然后一觉醒来又到了上班的时间了

上班

从成都回来，发生了一点小变化！我开始喝茶了！

在都江堰市买了一些本地的绿茶，20+、30+、70+不等。我正在喝的应该是是 70+（一两）的绿茶，算是比较贵的了。

本来我是完全没有喝茶的习惯的，但是平时跟着同事染上了坏习惯：时不时买个饮料喝。

我寻思要不直接试试喝茶吧，不用买饮料喝，也不买咖啡了。于是就多拿了两个杯子，用来倒茶水。一泡二泡三泡的，也不太懂，只知道大概的时间，别太长就行。

入口微微的苦和涩的感觉，喝下去有点回甘，感觉还不错。

第一泡时，茶叶会从卷曲的状态逐渐蠕动开来，变成翠绿的芽，这个过程很是解压，像是生命在生长的感觉

碎碎念

表弟家是重组家庭，还有个大他四岁的哥哥跟着他后妈过来。住院期间正好他哥在订婚，舅舅还想让我订婚当天也过去，但是我看大家都过去了，他自己在医院难受，还叫自己朋友过来陪床，实在有点可怜的了，所以就没有去，选择了在医院陪床。

如果是自己有两个孩子，一个生病住院，一个订婚。如果没人陪，想想就难受啊。

所以二胎不仅仅是钱的问题，责任也太太重了。

也许新手父母不清楚如何做好一个父母，但是最起码要懂如何和朋友处好关系。把孩子当成自己支配的工具，所谓的父爱母爱也得不到孩子的认可，只是感动自己罢了。一个家，最重要的就是松弛和愉悦（我认为的）。想想如何和朋友保持距离，又时刻保持联系，也许是和孩子愉快相处的一个比较好的解吧。

that's all.

集市周报 Vol.02

Mon, 26 May 2025 00:00:00 GMT

成都七日游

上上周很突然的接到一个出差的通知，导致我上上周末直接飞到了成都。

并且由于上周的四川之旅让人沉醉，导致我完全忘了上上周干了什么，所以只能跳过了...😯

在去成都之前，我对西南那边的印象来自于《风犬少年的天空》，只觉得他们方言很好听很亲切，现在竟然突然有了这么一个机会！！

由于飞机上没有WiFi，我准备在微信读书里找本小说缓存一下看看，没想到又翻到了龙族，虽然高中的时候就看过了，但现在已经忘的差不多了，准备二刷一下。

上次坐飞机还是疫情前去印尼巴厘岛，遥墙机场早就忘了什么样了。而这次去成都，准备让家里另外的三大一小也飞过去玩玩，毕竟机会难得，如果不是来这边出差，可能不会狠下心来跑这么远旅游，所以就简单的总结了一下飞机起飞前的教程，供他们参考。

来到成都之后，没有感觉任何不适。温度和济南类似，湿度要大一些，但不感觉很潮，气候十分宜人。感觉灰尘也比较少，街道比较干净。

虽然早就知道成都是新一线城市，但看到春熙路、太古里的商业街武装到马路牙子的繁华之后，还是不由得感叹：济南在二线城市里，可能也排不到前面吧🥲，但房价还不低。

这次也比较幸运，出差的公司也比较松弛：不打卡，不考勤。

早上 9 点上班，中午 11 点 30 去吃饭。中午他们休息，我回酒店打游戏，下午 2 点继续上班，5 点 30 他们就要跑路。相当于上午两个半小时，下午三个半小时，下午他们还要下去逛逛，消费一下。

当然了，代码质量也惨不忍睹。

下了班我就去城里逛逛，一开始坐地铁，发现挺累的。后面我用滴滴打车 10-15 元就能从天府二街附近到宽窄巷子，也就懒得走路了。

宽窄巷子、春熙路、太古里、玉林路、川大南门，这几个地方我觉得玉林路最合我意，走在街头有种本地人的感觉，随手挑了一个店吃饭，老板还愿意和你聊几句，另外几个只感觉是个景点、打卡点。

但是我对象觉得玉林路和我描述的不一样，因为我说玉林路太好逛了，但是她来到之后以为是有很多能逛两步就能走进去看看的店，所以她感觉一般。

前三天是我自己去逛，觉得很轻松惬意的。周四开始一家人都来之后，感觉难度就超级加倍了，因为他们的情绪我会感知的比较敏感，总觉得有人觉得不满意，而且还要时不时抱抱孩子。行程也变成了从一个点到另一个点的赶，虽然我只完全参与了周六一天的都江堰+熊猫谷。

但总体来说，成都远远超出了我的预期！

如果能留在成都我也是十分乐意的，哈哈哈哈哈

最后一晚，以街檐口重庆街边火锅结束了成都之旅。辣的感觉有根烧火棍把我贯穿了。

回到济南之后，感觉清醒了不少，没有了那种浮躁的感觉。

看来时不时出去旅游放松一下还是很有必要的。

不能共情，就放弃幻想

每隔一段时间，我会偶尔审视（回想）一下周边感情问题。

可能是因为我有某些执念，总是抱有幻想。想着和父母的关系应该是这样的，和妻子的关系应该是那样的。

而现实是，父母永远不可能像自己想象的那样，他们只会按照自己的思维逻辑一直这样下去。另一半也不会在你希望得到理解的时候理解你。有时候就觉得，为什么已经是最亲密的人，他/她还会如此没有耐心。

但他们都有好的一面，在真正困难的时候都会毫无保留的站在自己这一边。至于这些衣食无忧的时候产生的这些焦虑，不过是我自己吃饱了撑的，想要贪婪的追求更高级的精神共鸣，而此时另一半对物质的要求还没有达成。

哪怕偶尔会产生一些小摩擦，只要把视角抬高，就能很快找到问题的重点。顺应另一半的情绪就好了。事实上，平时的负面情绪，只要自己不放在心里不停的放大，不用过当晚就会烟消云散。别人也没真的太当回事。

情绪和视野问题，父母如果没有刻意教学，长大后自己也很难意识到。

哪怕自己已经明白，纠结再多也改变不了任何人。但还是会把时间浪费在“矫情”上。

无所顾忌的对自己热爱的东西释放热情，才是真正有意义的事儿啊

热爱的东西

我现在热爱的东西应该就是写代码。

讲真，如果我初中高中能学习美术等艺术类学科，我现在应该是一个设计师。但当时艺术生只是学习不好的一个退路。

现在回想起来，单论大学的话，如果一个脑子比较好使的人对艺术感兴趣，走艺术生高考能考上的大学要比学文理科强一些。不过艺术也容易陷入一些对崇高艺术虚无缥缈的追求里去，最终的热爱被现实击打后可能就只剩下考公考编了。而理科生对应的互联网行业则更加宽容和开放一些。虽然互联网行业对大学专业没有很多硬性要求，但如果父母对非编制类的职业缺乏理解的话，步入一个理想的行业也就更困难了。

虽然现在依然对这些东西抱有热情，但 30 岁的时间成本高的吓人。丧失了学生时代的大把时间的从零学习的机会，工作以后再想接触就只能速成了，但速成一般只是为了工作或赚钱，这只会让自己对热爱失去热情。再者，以前我可能还可以说自己是一个勤快的人，现在的我是真的懒了。我离不开任何时代赋予我的环境，只能把属于自己的帐篷尽力撑的高高的，这样在帐篷里休息才会显得轻松自在一些。

早早集市

最初我确实对这个产品抱有一定的幻想，但随着时间的推移和开发进度的推进，现在越来越觉得它也只能是服务于自己，离商业化差的很远。

因为虽然做的是商业化的梦，但实际的行动都是理想的个人主义。

在赚钱方面毫无意义，但对于个人的沉淀来说意义还是比较大的。多了一些记录的乐趣，一个独立自由的空间。不用担心琐碎的功能，只要被我集成在一起的，肯定是自己常用的并且用的顺手的。

少了贪婪欲望的驱使，开发的进度反而更加平缓有力了起来，不再有起起伏伏的情绪和动力上的波动。

接下来要做的应该是增加几个文章的来源（Nuxt Content），以及对于一篇文章的注解/评论引用功能。

然后要做的就是一个热力图，类似 Github 活跃度。但并非只有发了文章，写了代码才会有一个绿色的块块，其他都是灰色的。对于人生而言，工作、娱乐、健身、旅游等等一样重要，无论怎么度过一天，应该都有颜色。

然后就是补充自己的知识，再不断输出内容了。

好吧，这就这样吧！👏

济南遥墙机场起飞指南

Mon, 19 May 2025 00:00:00 GMT

必带

身份证

出发

9:25 的飞机

我 6:45 出发

司机走经十路+高速（8 元高速费），7:10 ~ 7:15 左右到达，用时 20-30 分钟，全程 15 公里左右，费用 x（我走的企业订车）元

达到遥墙机场航站楼二楼（坐飞机都是去这里）

到达后选择任意入口进入，因为都是通往一个大厅

值机大厅

大厅只有两个作用：取机票和托运行李

进入大厅后是这样的

图中左侧，也就是进门后正对的墙上会看到 B区 13-32，指的是值机口，值机口用于办理行李托运。

图中右上角，也就是进来后你的头顶，标的是登机口对应的检查区域（安检区）。

所有登机口对应区域如下图

这两个口可以在你的航旅纵横 App 上清晰的看到。

进来后先找自助机器拿机票。

拿到机票后，去值机口办理行李托运。

然后这个大厅里的全部就已经办完了。

这个时候不要去吃永和豆浆最低 49 元的六个小笼包+一碗豆浆的套餐。留着买它 17 个蛋烘糕不香吗！！

直接去安检区排队安检

安检需要机票+身份证。

排队 -> 交替通行 -> 拍照，进入后。需要拿托盘，把包里的电子设备都拿出来放入托盘中，然后把剩余所有东西也都放入托盘。

两手空空去检查身上有无违规物品

检查后，拿走行李，就来到了候机厅，这里也有吃不起的餐厅。

在这里找到自己的登机口，就近等待服务人员喊着自己的飞机开始检票的通知

主要路线

到达航站楼，任意口进入
自助机器取机票
拿着机票去值机口办理托运
去登机口对应的安检区排队安检
找到登机口等待上飞机

完全自建博客站需要付出的成本

Thu, 15 May 2025 16:30:37 GMT

如果不依靠第三方平台，完全使用自己的服务器自建博客，需要哪些成本?

云/轻量服务器

一般借助了第三方框架时，会选择类似 Vercel 的平台部署自己的网站

但如果完全自己部署，必不可少的需要购买服务器。

以 2核8G 的腾讯轻量服务器为例，每年大概需要 500 元左右的费用

之所以需要 8G 内存，是为了实现一个在服务器自动化打包部署。

NodeJS 在构建时会吃掉大量内存。其次，服务器本身需要一些内存来运行 Nginx、Docker、Gitea等。

如果不用自动化部署，写文章和写代码部署代码会耦合在一起，十分恶心。

像是平台化的一些建站工具，也是给了你一个 GUI 界面，自己点点部署按钮之类的

还要考虑部署到国内还是国外

国内意味着要备案，还可能会不让你弄评论系统

而服务器我都是挑着搞活动买的，一般第二年没优惠的话，就不会再续

换服务器就又要备案！

所以索性买海外服务器了，目前看来国内访问速度也不慢，首页打开在 2s 之内

SSL证书

SSL 证书是不可能花钱买的，我目前是配合 cerimate 自动申请+部署证书。

域名

非 .com 的一年小几十，.com 大几十或者 100 出头

图片

我花了 99 买了腾讯的对象存储，外加 CDN （99？），专门用来存文章里的图片。

但平台本身就有操作和理解门槛。还要设置防盗，限流等等。

也许对于一个普通博客站来说，使用 unjs/ipx 就够了

指定只能自己的域名访问图片

存储的话，可以写一个上传接口，传到服务器上

也可以直接就和项目代码放在一起，用 public 目录管理图片

编码

自己写要想选个框架吧

要设计 UI 吧，光 UI 就得纠结一阵

功能一大堆

权限？

通知？

写完了，好

一看，一天访客不到十个人

不过也有一些好处

比如写文章的素材多了很多（但是似乎太多了也懒得写，太少了也懒得写...）

对技术的应用会有更深的理解，如果平时会思考一些架构问题，自己动手实践一个真正的全栈会很有好处

最后

放在前两年，肯定时间成本会比较高，因为毕竟需要有一定的编程基础。但是现在 AI 的增幅效果越来好

今天的你在只借助 AI 的情况下也能完成开发工作，但在有一位开发者朋友或开发者交流群的情况下会更容易向 AI 问出正确的问题。

当然，一但付出时间和精力，就又要面对“这件事到底有没有意义”的问题上，如果你天生不内耗，那是极好的。但是一旦像我一样会时不时内耗，就不得不思考一下。谨慎的评估那些所谓的把时间花在有用的地方。不要听到别人说时间很宝贵，要花在能产生明确收益的地方，就停下手里的规划。

要考虑一下这些逻辑对于你目前的社会状态来说合适不合适

你的时间有那么珍贵吗？

花在所谓的有用的地方或玩乐的地方，有正向的反馈吗

如果你最近 1-3 年一直在尝试，可以试着回想一下，收获了什么

这些时间用在寄托了暴富的副业、活动上，真的比那些用时间换钱的“苦活”收益更大吗

有时候，能定义自己是一个什么样的人，恰恰是当下正在做的看起来毫无收益的事。

磨磨唧唧的终于把访客点赞评论功能加上了

Thu, 15 May 2025 16:14:38 GMT

现在可以基于前端生成的指纹 id，作为游客身份直接互动

🫡

[[zzao/the-cost-of-build-own-blog|the-cost-of-build-own-blog]]

Nuxt Content 实现 TOC 组件

Tue, 13 May 2025 00:00:00 GMT

TOC 全称 table of contents ，指的是一篇文章内的 h1、h2、h3 等标题的导航，用于快速跳转到对应的标题处。

Nuxt Content 会为 markdown 内容生成 toc 数据。

通过 queryCollection 获取的 page 数据中，通过 page?.body?.toc?.links 拿到当前文章的 toc 数据

以《Nuxt 3.17 发布，对比3.16有一个重大改变》这篇文章为例，数据是这样的

[
    {
        "id": "更新日志",
        "depth": 2,
        "text": "更新日志",
        "children": [
            {
                "id": "数据获取改进",
                "depth": 3,
                "text": "数据获取改进"
            },
            {
                "id": "新增内置组件",
                "depth": 3,
                "text": "新增内置组件"
            },
            {
                "id": "路由改进",
                "depth": 3,
                "text": "路由改进"
            },
            {
                "id": "加载指示器自定义",
                "depth": 3,
                "text": "加载指示器自定义"
            },
            {
                "id": "文档作为包",
                "depth": 3,
                "text": "文档作为包"
            },
            {
                "id": "开发体验改进",
                "depth": 3,
                "text": "开发体验改进"
            },
            {
                "id": "模块开发增强",
                "depth": 3,
                "text": "模块开发增强"
            },
            {
                "id": "性能改进",
                "depth": 3,
                "text": "性能改进"
            },
            {
                "id": "其他改进",
                "depth": 3,
                "text": "其他改进"
            }
        ]
    },
    {
        "id": "主要影响点",
        "depth": 2,
        "text": "主要影响点",
        "children": [
            {
                "id": "useasyncdatausefetch",
                "depth": 3,
                "text": "useAsyncData、useFetch"
            },
            {
                "id": "_2025年05月06日093334-更新",
                "depth": 3,
                "text": "2025年05月06日09:33:34 更新"
            }
        ]
    }
]

一般一篇文章里，h1 表示的是文章标题，在一个页面中通常只会存在一个 h1 标题，所以在写文章时，要注意不要乱用 # 标题这个语法。 h2、h3、就是文章里常用的二级和三级标题，在数据中就是 depth 为 2 或 3

组件本身使用 ul 、li 来渲染即可，再配合 fixed 或 sticky，使其国定在文章的一侧。

对于 Nuxt 来说，TOC 组件可以完全是一个客户端组件，因为不需要被爬虫抓取，也不是初次渲染需要的重要信息。而且如果要做一些简单的交互，也需要等前端环境加载出来之后才能做到。

所以只需要使用一个 computed 拿到 toc 数据，然后把数据传递给组件即可。

我观察了一圈，感觉少数派的 TOC 组件是比较美观的，于是我仿照他们的思路封装了自己的 TOC 组件

toc 的配置位于 nuxt.config.ts ：

content: {
	build: {
		markdown: {
			toc: {
			  depth: 2,
			  searchDepth: 2
			}
		}
	}
}

默认深度是 2，我一般会用到 3。

同时，如果要想自己定义 h1、h2、h3 标题的样式，需要在 app/components/content 目录下新建 ProseH1.vue、ProseH2.vue、ProseH3.vue 组件。

写样式时，不管如何封装，记得不要丢掉 id 属性

ProseH3.vue 为例

<template>
  <div :id="props.id" class="heading my-4 cursor-pointer scroll-mt-14">
    <span class="px-2 py-1 text-xl font-bold bg-zinc-800 text-white dark:bg-zinc-200 ">
      <a v-if="props.id && generate" :href="`#${props.id}`" class="!text-zinc-200 dark:!text-zinc-800">
        <slot />
      </a>
      <slot v-else />
    </span>
  </div>
</template>

<script setup lang="ts">
import { computed, useRuntimeConfig } from '#imports'

const props = defineProps<{ id?: string }>()

const { headings } = useRuntimeConfig().public.mdc
const generate = computed(() => props.id && ((typeof headings?.anchorLinks === 'boolean' && headings?.anchorLinks === true) || (typeof headings?.anchorLinks === 'object' && headings?.anchorLinks?.h1)))
</script>

对应 TOC 组件中：

# template v-for child in link.children
<li>
    <span>#</span>
    <NuxtLink :href="`#${child.id}`"> {{ child.text }} </NuxtLink>
</li>

也可以像我的组件一样，配合 IntersectionObserver ，做到 TOC 组件的导航根据滚动的区域使其高亮或是显示其他标识

 const headings = document.querySelectorAll('.heading')
	observer.value = new IntersectionObserver((entries) => {
	  entries.forEach(entry => {
		if (entry.isIntersecting) {
		  activeId.value = entry.target.id
		}
	  })
	})
	headings.forEach(heading => observer.value.observe(heading))

目前对我而言开发Nuxt最舒适的UI框架

Tue, 13 May 2025 00:00:00 GMT

对于 Nuxt 来说，有很多前端 UI 框架可以选择。

比如官方的 NuxtUI 、NuxtUI Pro，以及我的博客最开始用的框架 Primevue，都算是比较省心的框架。

但是对我来说，这几个框架用在 Nuxt 上就像是 ElementUI 用在了 Vue 的后台管理系统上一样，确实省事，也足够标准，但是前提都是你不会去二开他们的样式和功能。

一但现有的样式不满足你的审美，某个组件的功能差强人意，但心里就是感觉膈应。一切就不是那么美好了。仿佛是某个客户要求你把 ElementUI 的样式全都大改一遍，以达到他们心中的高端形象。

所以我最终选择的是 shadcn/vue + inspira-ui

shadcn/ui 在 React 那边是很火的，可能有人不知道他也有一个 vue 的版本。

使用方式是把组件下载到项目本地，所以给了你最大的可控性。

同时里面的有些组件，比如 sonner ，用的是 vue-sonner，已经是经过很多人验证的，在 toC 领域算是很美观的交互组件。还有 drawer 也是类似的情况，我觉得还是蛮方便的，把好用的组件都集合在一起。

inspira-ui是对 shadcn/vue 的一个补充和升级，主要用来实现一些炫酷的动画、特效。灵感来自于 Aceternity UI, Magic UI，填补了 vue 生态下相关组件的空白。

有这两个组件库，外加 tailwindcss ，不管是开发管理系统，还是面向用户的美观页面，都没有发现不够用的地方。

推荐你也去试一试～

集市周报 Vol.01

Mon, 12 May 2025 00:00:00 GMT

集市周报 Vol.01

😎五一

五一期间一家人回到了丈母娘家。

每一年里比较长的假期基本都会回去，因为平时我爸妈和我们一起住，帮我们带孩子。

孩子姥姥家离的比较远，230 公里左右，开车两个半小时。

对于两个懒 b 打工人来说，一般周六是没有上午的，醒了可能就在床上看看中午吃啥了。如果周六回去的话，早上正常起床吃饭收拾东西出发，到家一般也得下午 1～2 点了。而且爸妈他们平时不咋休息，都是在厂子里上班，我们回去他们可能还要请假，或者抽空回来，所以我们一般只挑长假期回家。

每次回去，心情都会格外的好。

大部分原因是因为丈母娘家的人和亲戚让我感觉到很舒服，说话从不拐弯抹角，给他们买了东西虽然也会和所有父母一样先说两句少花钱扒拉扒拉，但会很快接受，并且给予一些正反馈，不管是因为我是女婿或客人还是其他原因，至少我每次的感受都比较真实。

反观我父母。我心平气和，合理克制的回想一下。他们真的不会对自己家的人的善意表达感谢，倒是有同事或者陌生人如果帮了他们，或是和他们聊起自己的事儿，他们会记得一清二楚，并会在家里反复讲述别人的故事，仿佛还在引以为傲。

罢了，槽点太多，一直吐槽也是在消耗能量。让生活回到自己的掌握之中，还是要靠自己多做一些有能量、有意义的事。自怨自艾只会让别人牵着鼻子走。自己？没错，是自己。哪怕是伴侣，也不可能在所有方面契合，三观一致都已经是谢天谢地了。但不管是和什么样的人相处，让自己学会搞钱才是第一位的，这是对所有人的正反馈。

每次回去，行程安排的也比较满。

除了日常的走亲戚串门之外，这次还去了离家只有 30 公里左右的海边。

这回我是真赶上海了，以前只在 B站刷一些赶海视频，觉得十分有趣。这回终于来到了一片儿能赶海的区域。

因为这边靠近黄河入海口，所以这边全是泥滩，而不是沙滩。让我震惊的是，这海水退潮竟然能退到那么远吗🥲，远处的人都成了一个小点儿了，感觉有个小几公里远。

可惜这次没带装备，把孩子扔给姥姥姥爷后，我俩就去里面转了一圈就出来了。当然也不是全无收获，有两只“一斤大”的螃蟹🦀

因为我们是大中午头来的，离岸比较近的地方早都被人扫荡一空，脚印比气孔还多，而且全是淤泥。下次再来的话，必须得早点来，然后带上家伙！

不过爸妈表示这是花钱找罪受（40 元/人），我俩倒是十分喜欢这种满地寻宝的感觉。

五一假期转瞬即逝。

🫨工作

和去年比，今年的工作简直就是地狱一般。

时不时就开始冲刺，2 月冲完 3 月冲，3 月冲完 4 月冲。让我不禁有些怀疑这还是不是之前的养老圣地。

但是好在工作内容早已固定，我也不期望在公司能有什么历练和成长了。要非要说还有什么成长空间的话，可能就是直接和客户对接或负责整个项目吧。但毕竟是个前端，一般是不需要参与具体的业务的，所以目测也不会有这样的机会了。

对于平时的工作，我在可以优化的地方已经做好了 CLI 工具，可以直接化繁为简，专门解决掉一些繁琐但又不得不做的工作。本来我还犹豫要不要上报给领导，领一份嘉奖，但是现在可以非常肯定不会这么做了。

因为我们的工作，就是做这些重复、无用、繁琐的东西。我们存在的意义，也是和费时挂钩的，如果对于公司的工作以及对于客户花钱购买我们的项目和人力来说，真的不费时了，大概也不是一件好事。还是在私下里使用，让大家节省一些时间，拿去摸摸鱼吧。

省下的时间，大部分是用来做这个博客的项目了。

正在做的博客

合了分，分了合，最终功能推进的并不快，因为实在是没什么正反馈，做着做着也没有一开始的兴奋劲儿了。

搞技术的东西，好像就是研究的时候比较上头。研究完了，写出来，发现和一坨狗屎也没什么区别，提不起一点兴致。

也不是一点兴致没有，但我们懒人写代码，就和跳大神做法一样，需要的仪式和前置条件比较多，但凡天气不好、季节不好、心情不好，今天恐怕又是要在摸鱼中度过了。

更何况没有一点额外收入，还要有一笔开销来维持住服务器的正常访问。大环境偏偏又不好了，生怕哪天没了工作。虽然我坚信我可以很快再次找到一份工作，但薪资方面恐怕要打个折扣了。

不管怎么样，还是继续搞吧。

有私活接的话，就先干私活，没有也只能先写点自己的代码了。

毕竟这个 App，我构思了很久了，现在感觉（未来）很贴近自己的生活场景，就当是一个互联网遗产吧。以后哪怕不做程序员了，写点文章，发发牢骚也是个不错的爱好。考虑到换行的话，大概率不会像这样每天敲代码了，所以一个全栈项目是肯定的了，打磨完善后可以只记录、发表、分享，什么开发新功能啥的，够自己用就行了。希望能早日完成早早集市吧 😩

果然星期一就是适合碎碎念，摸摸鱼，完全不适合工作啊 😏

Cli工具集成到Electron客户端

Thu, 10 Apr 2025 00:00:00 GMT

背景

给公司开发了一些小脚本，发布为了一个命令行工具

前端小伙伴反馈说，命令行要比客户端好用，因为只敲了很少的命令就完事了

但对于非前端开发者，Node 环境问题比较头疼，而且如果是非技术人员，可能命令行也无法接受

之前把单独一个功能复制粘贴再改改，集成到 electron 里去过，但工作量太大

最近又有了新思路之后，尝试了一番，花了大概俩小时，把之前的 cli 的大部分功能搬到了客户端上

核心思路就是：

原CLI须用Bun进行打包为二进制文件, electron中直接使用 child_process.spawn 执行, 监听输出信息返回到前端进行展示

前端中需要有一个配置文件 src/config.ts, 来表示自己的 cli 有哪些 command 可以运行

就是这么一个简易的UI

Cli打包

目前仅可打包支持esm的包, 如sharp这种c++包还在研究中

安装bun

macos

curl -fsSL https://bun.sh/install | bash

wind

powershell -c "irm bun.sh/install.ps1 | iex"

打包到指定平台

具体请看官方文档: 支持的平台参数

RUNTIME_ENV=electron bun build ./src/index.js --compile --target=bun-darwin-arm64 --env inline  --outfile z-cli
RUNTIME_ENV=electron bun build ./src/index.js --compile --target=bun-windows-x64 --env inline  --outfile z-cli

RUNTIME_ENV 的用途是兼容 cli 里的一些和 electron 无关的代码

如检测 package.json 中信息, 打包后就不存在 package.json 了, 所以原项目中使用此环境变量过滤一下

Electron 配置

resource/bin

把打包后的二进制文件放在此目录下

ipc.ts 以及 App.vue 中修改 z-cli 相关字符(binaryName/channel) 为 自己的cli名称

Vue 配置

src/config.ts 修改为自己 cli 的命令配置

打包/调试

最终构建好的客户端, 包含一行命令的下拉栏, 以及一个执行结果

原本 cli 的配置文件等都会复用

相当于只是把 cli 的敲命令过程可视化, 把结果照搬到 electron 中

注意

注意下 cli 里的依赖包,是否兼容 bun

如:

axios 需要替换成 fetch
sharp 可能在构建成客户端后会报错 (待解决)

开源地址

Github

使用 pm2 启动 ipx 服务(bun运行时)

Tue, 08 Apr 2025 00:00:00 GMT

在给 imgx 的预设静态化图片启动服务时，我使用了 unjs/ipx 来作为图片服务，这样可以直接进行格式转换和裁剪

后续图片操作（x）也必然涉及到要先把图片存储再操作，所以还是单独启动一个服务罢了

考虑到 bun 的吞吐量要比 node 大一些

于是使用此命令来启动 ipx 服务

bunx ipx serve --dir ./public

对应到 pm2 的 config.yml 上配置为

apps:
  - name: imgx-nitro
    script: ./server/index.mjs
    interpreter: node
    exec_mode: fork
    env:
      PORT: 1234
  - name: imgx-ipx
    script: bunx
    args: ["ipx", "serve", "--dir", "./public"]
    exec_mode: fork
    env:
      PORT: 5678

注意不需要指定 bun ，直接使用 bunx 即可

系统为 Debian12.0 ，供诸君参考

人不 EMO 枉青年

Thu, 27 Mar 2025 00:00:00 GMT

最近时不时加个班，难受！🤦

本来还想着下家跳槽到一个国企，虽然知道他们加班加的多，但是好歹稳定一些，薪资也不低，公积金高，就当固定存储，老老实实当个牛马。

但是经过最近一个月的高强度加班，我发现我可能是接受不了这种公司

哪怕已经是心平气和，没有百分百投入的敲代码，从早熬到晚的作息依然对人的精神是巨大的伤害

本来我以为人只有身体的上的痛苦才算是真正的痛苦，精神上的痛苦只要想得开，没有过不去的。

现在看来，过去是真能过去，但过程实在是痛苦。

对身体的摧残还是其次的

长时间加班对精气神的摧残更大

一个人的精力很有限，尤其是没有长期运动习惯的人，精力更是十分有限

被加班这么一折腾，打击的是自己做事的动力和想法

如果平时工作按部就班，生活简简单单，哪怕有一些鸡毛蒜皮，自己也能过滤掉。然后还能神清气爽的规划和研究一些自己或家人真正有兴趣做的事。

被加班消耗掉原本的精力之后，下班后只想休息、玩、睡觉，这还是次要的。

被打断的思路，或是正在做的事，很容易半途而废。

人这一生又有多少件事，是能自己一手规划，又完完整整的实施下来的呢？

家人或朋友的不理解已经被视为“正常”，自己还要向工作妥协，甘心做个牛马。

我咽不下这口气

尤其是在 30 岁这个"适合"投入大量时间探索的年纪，偏偏琐事缠身

20 岁以前懵懂、无知，只知道学校最大，老师最大，家长最大

等到和社会接轨，现实和理想又差距巨大

然后在磨合到真正知道自己想干什么，该干什么的年纪

很多事又已经由不得你做出选择

可悲的人儿啊

在混沌中浮沉，周围全是要"拉你一把"的一双双的手

Z-CLI 使用说明

Fri, 21 Mar 2025 00:00:00 GMT

安装

Node

使用 nvm 管理多个 node 版本

node >= 18.18.0

推荐版本(我的)：20.18.1

查看 registry （非必要步骤）

npm config get registry
# https://registry.npmjs.org
# 如果不是，则需要先设置
npm config set registry=https://registry.npmjs.org

安装最新版

npm i -g @zzclub/z-cli

安装后只能在当前 node 版本下使用，切换到其他低版本 node 则无效

全局命令为：zz 或 z

Bun

macos

curl -fsSL https://bun.sh/install | bash

wind

powershell -c "irm bun.sh/install.ps1 | iex"

安装最新版

bun i -g @zzclub/z-cli

如果提示缺少某个包，可以按提示再次运行相关命令

命令

i18n 缩写 i 从Vue文件提取出中文国际化文件
translate 缩写：trans 批量翻译中文国际化文件
set 设置配置文件
tiny 任意图片压缩体积

i18n 规则说明

文件

只提取 .vue 文件

`$t`解析及生成规则

提取正则： /\$t$['"]i18n\.([^'"]+)['"]$/g

举例：

$t('i18n.module-name.placeholder.month')

module-name 会被解析为文件名称 => module-name.js
后面的内容会被解析为对象的属性 => { placeholder: { month: "month"}}
保存位置如果没传。就会保存在 .vue 同级目录下
默认忽略 module-name 为 common => $t('i18n.common.xxx')

中文注释规范及提取规则

<template>
  <!--i18n addTitle=你好呀 a=不错   b=叭叭叭 c=哈哈哈  -->
  <CommonEditForm :page-type="pageType" :title-config="titleConfig" :custom-components-code="$t('i18n.monthlyForecast.pageTitle.addTitle')" :is-out="2">
    <div>{{ $t('i18n.monthlyForecast.form.a') }}</div>
    <div>{{ $t('i18n.monthlyForecast.form.b') }}</div>
    <!--i18n select=真棒 -->
    <div>{{ $t('i18n.monthlyForecast.placeholder.select') }}</div>
  </CommonEditForm>

</template>

<!-- js 区域 -->
<script>
   import {formatDate} from "@/common/utils"
   import CommonEditForm from "@/pages/ifpf/costForecast/monthlyForecast/views/common-edit-form.vue"

   export default {
       name: 'ifpfExchangeRateMaintainAdd',
       components:{
           CommonEditForm,
       },
       data() {
           return {
               pageType: 'edit',
               titleConfig: {
                   title: this.$t('i18n.monthlyForecast.pageTitle.addTitle'),//测试
                   icon: this.$t('i18n.monthlyForecast.pageTitle.icon'), // 图标
                   date: formatDate.formatDateOnly(new Date()),
                   info: this.$t('i18n.monthlyForecast.pageTitle.addInfo')//你好
               },
           };
       }
   };
</script>

解析后：

export default {
  pageTitle: {
    addTitle: "测试",
    icon: "图标",
    addInfo: "你好"
  },
  form: {
    a: "不错",
    b: "叭叭叭"
  },
  placeholder: {
    select: "真棒"
  }
}

template 中的注释，必须以 <!--i18n 开头
template 中的中文配置以 空格 分割，以 =号拼接key=value, 如 addTitle=你好呀 a=不错
template 中支持多个注释信息
template 中的 key=value 的 key 对应 $t中最后一个key
js 中支持两种注释信息提取
- $t() 后紧跟 // , //后的中文内容都被视为默认值
- $t() 后存在 , 、空格 这两种符号，然后再跟 //, //后的中文内容都被视为默认值

解析完成后，自行把文件挪到到 zh-CN 文件夹下

然后使用 translate 命令进行中译英

翻译功能配置说明

初始化翻译平台appId和key

zz set translate account.appId xxx
zz set translate account.key xxx

在哪里可以创建appId和key

请使用前仔细阅读百度翻译开发平台相关规则

百度翻译开放平台

注册
实名认证
1. 标准版 qbs 1 每月5万字符
2. 高级版 qbs 10 每月100万字符
开通通用文本翻译功能
生成appId和key
生成后的文件请仔细检查，有可能会有遗漏的翻译，如有，重新执行即可
注意: 百度翻译的api有一定的调用限制, 请自行评估是否需要使用高级版

翻译单个文件

zz translate -f ./yourfile.js
# 会在同级目录下生成 yourfile-en.js

如test.js

export default {
    isok: '早早下班',
    common: {
        listTitle: '标题',
        addTitle: '测试'
    },
    test: {
        a: {
            b: {
                c: '哈哈哈'
            }
        },
        aaa: {
            value: '输入'
        }
    }
}

输出文件为test-en.js, 内容如下

export default {
    isok: "Leave work early",
    common: {
        listTitle: "title",
        addTitle: "test"
    },
    test: {
        a: {
            b: {
                c: "Hahaha"
            }
        },
        aaa: {
            value: "input"
        }
    }
}

批量翻译

检索目标文件夹内所有langs文件夹下的zh-CN 文件夹下的所有文件, 输出至其同级的en-US下, 文件名同名

zz translate -d ./demo

如: demo文件夹是以下结构, zh-CN中所有JS会翻译后输出至en-US

每个文件输出内容同翻译单个文件

.
├── en-US
│   ├── test.js
│   ├── test2.js
│   └── test3.js
├── test-en.js
├── test.js
└── zh-CN
    ├── test.js
    ├── test2.js
    └── test3.js

翻译时可能存在翻译失败的情况，重新运行 translate 命令即可

压缩图片

使用help命令查看所有支持的功能

zz tiny --help

  -t, --type <fileType>         转换后的图片类型 (default: null)
  -f, --file <file>             要压缩的图片文件 (default: null)
  -d, --dir <dir>               压缩文件夹内所有文件 (default: null)
  -co, --condition <condition>  压缩文件夹内所有名称包含[--condition]的图片文件 (default: null)
  -q, --quality <quality>       压缩质量(1-100) (default: 75)
  -c, --colours <colours>       GIF色彩保留(2-256) (default: 128)
  -n, --name <name>             指定文件名输出 (default: "")
  -m, --max <max>               限制要上传的文件大小(kb)(仅当开启 --picgo 时会用到) (default: 60)
  --picgo [type]                调用picgo (无参数) (default: null)
  --no-picgo [type]             不调用picgo (无参数) (default: null)
  -h, --help                    display help for command

操作流程演示

按照规则写好 Vue 文件后，cd 到对应的文件夹

使用 i18n 命令，生成中文国际化文件

zz i18n -d ./demo

✔ 开始检索/Users/xxxx/demo
✔ 共找到1个要处理的文件
✔ 从 demo 中提取了 6 个国际化键值
✔ 生成文件: /Users/xxxx/demo/monthlyForecast.js
✔ 国际化文件生成完成

生成后检查有没有问题，自行完善生成后的文件

确认中文国际化文件完整后

把文件放到 zh-CN 目录下

使用 translate 命令翻译

zz trans -d ./demo
✔ 开始检索/Users/xxxx/demo
✔ 共找到3个要翻译的文件
✔ /Users/xxxx/demo/en-US/test.js已翻译
✔ /Users/xxxx/demo/en-US/test2.js已翻译
✔ /Users/xxxx/demo/en-US/test3.js已翻译
✔ 翻译完毕

到 en-US 目录下检查翻译情况

Nuxt 中设置代理的正确姿势

Thu, 20 Mar 2025 00:00:00 GMT

通常在一个前端项目中，后端接口可能不是和前端 Nuxt 集成在一起的（Nitro)

而前端从浏览器发出请求时又会遇到跨域问题，为了解决浏览器跨域问题

除了能直接设置代理服务器的CORS，就需要用代理服务器转发的方式解决

代理的原理很简单：把当前域下的前端往目标服务发送请求，改为向当前域下的代理服务器发送请求，代理服务器直接转发前端请求到目标服务并把 response 返回给前端

这样，同一个域下不会产生跨域，而服务端之间的请求又不存在跨域问题，就解决了问题。

在 Nuxt 中有四种方式可以设置代理，而最后一种则是终极解决方案

一、Vite sever proxy

在 nuxt.config.ts 可以设置 vite 配置，就和 Vue3项目一样

vite : {
	server: {
      proxy: {
        '/api/v1': {
          target: 'http://localhost:5770',
          changeOrigin: true,
          rewrite: (path) => path.replace(/^\/api\/v1/, '')
        }
      }
    }
}

此时项目内请求 /api/v1/user/list 时，会被转发到 http://localhost:5770/user/list

/api/v1 在此处被重写了，所以实际请求到 5770 时是不携带这个前缀的

使用 vite server 代理时，和 Vue3 项目一样，仅对本地开发时有效，适合项目部署到时和实际后端服务的服务器、域名、端口一致的情况下使用

二、Nitro devProxy

在 nuxt.config.ts 可以设置 nitro.devProxy 进行代理

 nitro: {
	devProxy: {
      '/api/v1': {
        target: 'http://localhost:5770',
        changeOrigin: true
      },
      '/api/v2': 'http://localhost:5771'
    }
 }

这样可以借助 Nitro 在开发时进行代理，原理和 Vite server 没有区别

这个选项使用 unjs/httpxy 实现，可以在官方文档查看

以上两种方式，在使用 useFetch 可以通过开启 server 选项来测试是否在 SSR 下生效。

三、Nitro routeRules proxy

比起 devProxy ，routeRules 配置是更好的选择

nitro: {
	routeRules: {
      '/api/v1/**': {
        proxy: 'http://localhost:5770/api/v1/**'
      }
    },
}

既可以在客户端请求时生效，也可以在 SSR 期间生效

唯一的问题是在运行时设置环境变量不太方便

因为就算把 proxy 换成环境变量里的值

proxy: process.env.YOUR_SEVER_URL

也只会在构建时生效，这个值会被硬编码进应用中。

和直接写在proxy里唯一的区别是：你可以在不同的服务器中构建，再针对不同的构建环境设置不同的环境变量

所以，Nuxt 中如何在运行时读取环境变量？runtimeConfig !

代理只是一个 node 服务，我们当然也可以使用 Nitro 自己实现代理行为

四、Nitro proxtRequest()

在 Nuxt 中，runtimeConfig 是个比较特殊的配置

Nuxt 不在生产环境（运行时）中读取 env 文件，只在开发、构建、生成（generate）时读取（因为不同部署环境的兼容性，比如无服务器平台、cloudflare workers 等）

所以才有了 runtimeConfig 这个配置，用于在运行时读取特定的环境变量。

不同的平台有不同的环境变量设置方式，在 Nuxt 中通过读取 NUXT_ 前缀的环境变量来和 runtimeConfig 里的 key 对应起来

比如：

runtimeConfig: {
    proxyUrl: 'http://localhost:5770',
},

在运行时，使用 useRuntimeConfig 读取 proxyUrl 时，会优先去读 NUXT_PROXY_URL 这个环境变量，如果没取到就会使用当前字符串

所以如果要切换服务，只需要在对应的部署环境中修改 NUXT_PROXY_URL 即可，无需再重新构建

理解了这一点，接下来就是借助 Nitro 来实现代理行为。

首先需要在 server 目录下的新建 api/[...].ts，然后实现以下内容：

import { joinURL } from 'ufo'
export default defineEventHandler(async (event) => {
  const proxyUrl = useRuntimeConfig().proxyUrl
  
  const targetApiPrefix = event.path.replace('xxx', '') 
  const targetUrl = joinURL(proxyUrl, targetApiPrefix)

  return proxyRequest(event, targetUrl)
})

思路和配置代理的思路是一样的，因为核心部分 proxyRequest 已经实现了

我们要做的就是：

拿到实际的服务地址。通过 runtimeConfig 可以拿到任意动态的地址
根据前缀和实际服务地址对应起来。类似配置时的 /api/v1: 'http://localhost:5770' 和 pathRewrite
proxyRequest

其中第二条对应的就是 targetApiPrefix 的逻辑，假设 Nuxt 应用发出的请求是/api/imgx/xxxx ，对应 imgx 服务中的 /api/v1/xxxx

则这样实现：

const targetApiPrefix = event.path.replace(/^\/api\/imgx\//, '/api/v1')

此时在 Nuxt 中发出请求是这样的

$fetch('/api/imgx/img/001/001/哈哈哈')

Nitro 转发时就会变成 http://localhost:5770/api/v1/img/001/001/哈哈哈

由于这个接口我们拥有完全的可控性，所以能做的不只是代理

在隐藏了实际请求地址的同时

还能通过proxyRequest的第三个参数传入 { headers: { Authorization: 'your token'} }向目标服务添加身份验证信息

如果拥有多个后端服务，还可以自己选择转发到何处，达到类似负载均衡的作用

如果想对请求到的数据做进一步处理，又何必纠结于代理？

只需要自己使用 $fetch 请求明确的地址 targetUrl，然后对拿到的数据进行处理，再返回给前端即可！

_注意：借助 Nitro 实现代理，前提就是你得有 Nitro ，如果 Nuxt 完全静态化了，就无法动态读取环境变量了 _

总结

以上就是 Nuxt 中设置代理的四种方式

其中第一种和 Vue3 项目没有区别，是基于本地服务实现

如果你只需要在本地开发时使用代理来解决跨域问题，在生产环境中没有这个问题，那你可以选择前两种

如果你的代理地址比较固定，也没有很多不同环境的后端服务可用，那你可以选择第三种 Nitro routeRules proxy , 只需要配置，即可实现这个简单的需求

如果你的环境比较多，或是需要调用的服务也比较多，或是有很多特殊需求需要实现，那我推荐你使用第四种终极方案

当然，这只是基于 Nuxt 中的实现，利用 Nginx 也能轻松实现代理，可以根据自己的实际情况来抉择

希望对你有所帮助~

✨使用umami低成本监控网站流量

Wed, 19 Mar 2025 00:00:00 GMT

👀什么是Umami

Umami 是一款开源的、注重隐私的网络分析工具（基于NextJS），可作为 Google Analytics 的替代品。它提供有关网站流量、用户行为和性能的重要见解，同时优先考虑数据隐私。

与许多传统分析平台不同，Umami 不会收集或存储个人数据，从而避免了使用 cookie 的需求，并且符合 GDPR 和 PECR 标准。

Umami 设计轻巧、易于设置，可自托管，让用户完全控制自己的数据。

这是我部署后的界面：

同时包含了一些访客的浏览器、设备、操作系统等信息

以及 ip 所在国家

在行为类别中，还可以看到自己在网站中的埋点

总结： MIT开源、免费、独立部署的网站数据分析工具

安装

如果使用Docker那就非常简单了

# 直接在项目根目录运行
docker-compose up -d

# 或者使用下面镜像 二选一
docker pull docker.umami.is/umami-software/umami:mysql-latest
docker pull docker.umami.is/umami-software/umami:postgresql-latest

因为我已经存在一个正在运行的 Mysql Docker服务了，所以下面以从源码安装，并以 PM2 运行 Umami 为例

环境要求

Node >= 18.18

Mysql >= 8.0 或 PostgreSQL >= 12.14

安装yarn

npm install -g yarn

获取源代码

git clone https://github.com/umami-software/umami.git
cd umami
yarn install

.env 文件

创建一个 .env 文件，用于数据库连接

如果你还没有Mysql服务，可以参考我这篇：【使用Docker启动Mysql】

DATABASE_URL=mysql://username:mypassword@localhost:3306/mydb

将 username、password、mydb 都替换成自己的，其中mydb的创建可以参考：安装后如何初始化库和新用户

还可以配置 PORT=4577，端口号

PM2启动

yarn global add pm2
cd umami
pm2 start yarn --name umami -- start
pm2 startup
pm2 save

如果配置了PORT，PM2命令要对应的修改为

pm2 start yarn --name umami -- start-env

如果不用 env 文件，可以直接传递变量

pm2 start yarn --name umami -- start --port=6001

两种方式都可以。

pm2 startup 则是为了设置开机自启，save 会把当前配置保存起来

配置 Nginx

此处仅作为作为参考，适用于配置多个子域名，共用一个泛域名证书

http {
	# umami
    upstream upstream_umami{
        server localhost:6001;
    }
	map $host $proxy_pass {
        hostnames;  # 添加这行以优化域名匹配

		# ...省略其他子域名
        umami.xxx.com http://upstream_umami;
    }
	server {
        listen 443 ssl; 
        server_name *.xxx.com; #泛域名
        
        ssl_certificate /etc/nginx/certs/xxx
        ssl_certificate_key /etc/nginx/certs/xxx

        fastcgi_param  HTTPS        on;
        fastcgi_param  HTTP_SCHEME     https;

        location / {
            add_header X-Final-Destination $upstream_addr;
            
            proxy_set_header   X-Real-IP         $remote_addr;
            proxy_set_header   Host              $http_host;
            proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
            
            proxy_pass $proxy_pass; 
        }

    }
}

配置成功后，nginx -t 检测是否有错误，如果没错就 restart nginx

然后再访问配好的子域名 umami.xxx.com 是否有效就可以了

使用

umami 的使用也非常简单，首先打开 umami.xxx.com ，也就是自己配好的地址

基本配置

默认用户名: admin
默认密码：umami

找到用户这里

修改语言直接点击右上角的国际化图标即可

设置好后，在设置 -> 网站 -> 添加网站中，输入自己的网站名字和域名

添加好点击编辑按钮

然后就可以看到自己的网站lD、跟踪代码

接下来就是要把跟踪代码添加到当前网站项目中

以 Nuxt 为例

在 nuxt.config.ts 中，添加如下配置

export default defineNuxtConfig({
	app: {
		head: {
			script: [
				{
					src: 'https://umami.xxx.com/script.js',
			        defer: true,
		            "data-website-id": "your_data_website_id"
				}
			]
		}
	}
})

把 src 和 data-website-id 替换成自己的即可

重新打包、发布Nuxt应用后，umami的统计就会立即生效了，可以前往 umami.xxx.com 去看访问数据

埋点

要想记录某个按钮的点击行为，以及传递一些用户信息来记录，需要用到 Umami 的 Track Events

<button id="signup-button" data-umami-event="Signup button" data-umami-event-id="123">Sign up</button>

data-umami-event ：表示记录的事件名
data-umami-event-* ：表示给事件传递的属性 { id： "123"} 会这样被记录下来

这种使用 html 属性的方式，所有数据会保存为字符串，记录一些基本动作也是够用的

也可以使用 JS 的方式来主动调用

引入 umami/script.js 时，会在全局注入一个 umami 对象，所以直接使用：

umami.track(event_name: string, event_data: object);

如果不传 event_name，记录的就是页面浏览事件，比如这样

umami.track({ website: 'e676c9b4-11e4-4ef1-a4d7-87001773e9f2', url: '/home', title: 'Home page' });

记录时只会记录 url 和 title ，如果要包含 umami 默认的属性

umami.track(props => ({ ...props, url: '/home', title: 'Home page' }));

所以刚才按钮的事件可以这样记录：

umami.track('signup-button', { name: 'newsletter', id: 123 });

总结

以上就是 Umami 的安装和在项目中的使用。

内存占用方面，使用 node 作为运行时，pm2 显示umami占用内存在 80 ~ 200 mb之间，不知道流量比较大的站点内存消耗如何。

但作为安装、运行、使用上来说，umami 集成非常简单易用，推荐大家使用

欢迎在评论区交流

生成卡片的超长提示词

Wed, 12 Mar 2025 00:00:00 GMT

提示词

打磨了一下生成模板的提示词，用来批量生产模板

基于图片生成模板

我会给你一个图片，分析内容，并将其转化为美观漂亮的比例相同的 HTML 元素：

## 内容排版规范
	- 整体风格按照图片中的排版
	- 如何图片中有明显的样式不美观，则去除
	- 使用清晰的视觉层次结构，突出重要内容
	- 配色方案应专业、和谐，适合在社交媒体传播
## 技术规范
	- 使用 Vue3（通过CDN引入）、Tailwindcss3(通过CDN引入)
	- 使用 Vue3 渲染内容时，template 标签中只能使用两种方式定义样式
		1. class。如 class="w-full h-full"
		2. :style="{ color: myColor }"。这种方式用于接受 props 的参数，要满足 vue 语法
		3. 两者为互补关系，不能修改的样式全部用 class实现，动态传入的用 style 实现
		4. 至少在其中一个中声明 flex 布局
	- 使用 Vue3 渲染内容时，script 中只允许使用 props，props 中只能接受和内容、样式有关的数据。不允许存在任何交互逻辑
	- template 和 props 的内容要独立且完整，要用单独的变量存储。
	- template 中的内容要用 props 传入值或默认值代替，不能把 template 的内容写死。
	- CSS 请严格按照【CSS要求】，务必使用 tailwindcss3 的语法，同时要使用`:style="{}"`语法来保证能接受 props 来改变颜色、字号、间距等属性
	- CSS或 props 中不允许出现 undefined，必须有明确的值，如 width: 100%
	- html元素只能使用 div 元素
	- 每个 div 必须显式使用 flex 布局，必须具备 flex class
	- 不能使用 z-index 属性
	- 不能使用 satori 不支持的属性
	- 如果发现现有条件不能生成一模一样的样式，则放弃和原图保持一致，换一种简洁的样式来代替
	- 最外层 div 以及第二层 div 必须使用 `w-full h-full` 来占满父元素
	- 如果图片底部存在渐变色或底色，内容存在底色，要特别注意样式的准确性，必须表现在 Vue 组件内
	- 只允许最终生成单个HTML文件
	- 在 Vue 组件的外层增加一个固定宽高的 div 容器，用来模拟其固定尺寸的父元素
	- 在 Vue 组件的上方增加两个按钮
		- 1.复制 Template，点击时把 Vue 组件中的 Template 变量的内容当做字符串复制到粘贴板，要求和 template 共用一个变量
		- 2.复制 Props，点击时根据 Vue 组件中的 Props 对象的格式，生成key-value格式的对象字符串复制到粘贴板。
	- 代码中不要出现任何注释
## 媒体资源
	- 忽略所有媒体资源
## 图标与视觉元素
	- 忽略所有 emoji
	- 忽略所有 图标
	- 忽略所有背景图、复杂阴影效果
	- 不需要存在交互效果，只要视觉效果
## 性能优化
	- 确保页面加载速度快，避免不必要的大型资源
## 输出要求
	- 提供完整可运行的单一HTML文件，包含所有必要的CSS和JavaScript
	- 代码中不要出现任何注释
	- 确保代码符合W3C标准，无错误警告
	- 页面在不同浏览器中保持一致的外观和功能

请根据上传图片，基于 Vue3 创建出合适的卡片 HTML 网页内容。

让AI自主设计排版（待完善）

请基于 Vue3 在 HTML 中生成一个美观漂亮的卡片组件，同时满足以下要求：

## 排版规范
	- 整体长宽比为：3:4，用途为小红书、推特、朋友圈发帖
	- 配色方案应具有科技感，以合理的渐变作为背景
	- 文字必须成为视觉主体，占据页面至少70%的空间
	- 运用3-4种不同字号创造层次感，关键词使用最大字号
	- 主标题字号需要比副标题和介绍大三倍以上
	- 主标题提取2-3个关键词，使用特殊处理（如描边、高亮、不同颜色）
## 技术规范
	- 使用 Vue3（通过CDN引入）、Tailwindcss3(通过CDN引入)
	- 使用 Vue3 渲染内容时，template 标签中只能使用两种方式定义样式
		1. class。如 class="w-full h-full"
		2. :style="{ color: myColor }"。这种方式用于接受 props 的参数，要满足 vue 语法
		3. 两者为互补关系，不能修改的样式全部用 class实现，动态传入的用 style 实现
		4. 至少在其中一个中声明 flex 布局
	- 使用 Vue3 渲染内容时，script 中只允许使用 props，props 中只能接受和内容、样式有关的数据。不允许存在任何交互逻辑
	- template 和 props 的内容要独立且完整，要用单独的变量存储。
	- template 中的内容要用 props 传入值或默认值代替，不能把 template 的内容写死。
	- CSS或 props 中不允许出现 undefined，必须有明确的值，如 width: 100%
	- html元素只能使用 div 元素
	- 每个 div 必须显式使用 flex 布局，必须具备 flex class
	- 不能使用 z-index 属性
	- 不能使用 satori 不支持的属性
	- 最外层 div 以及第二层 div 必须使用 `w-full h-full` 来占满父元素
	- 如果图片底部存在渐变色或底色，内容存在底色，要特别注意样式的准确性，必须表现在 Vue 组件内
	- 只允许最终生成单个HTML文件
	- 在 Vue 组件的外层增加一个固定宽高的 div 容器，用来模拟其固定尺寸的父元素
	- 在 Vue 组件的上方增加两个按钮
		- 1.复制 Template，点击时把 Vue 组件中的 Template 变量的内容当做字符串复制到粘贴板，要求和 template 共用一个变量
		- 2.复制 Props，点击时根据 Vue 组件中的 Props 对象的格式，生成key-value格式的对象字符串复制到粘贴板。
	- 代码中不要出现任何注释
## 输出要求
	- 提供完整可运行的单一HTML文件，包含所有必要的CSS和JavaScript
	- 代码中不要出现任何注释
	- 确保代码符合W3C标准，无错误警告
	- 页面在不同浏览器中保持一致的外观和功能
## 用户输入内容

请根据上述要求，生成一个在单一 HTML 中可使用的Vue3卡片组件

修改生成卡片的样式时，只需要修改排版规范部分即可

测试：社交卡片

## 排版规范
- 仿照X/twitter的帖子格式来设计卡片
- 排版规范、美观、整齐
- 文字必须成为视觉主体，占据页面至少70%的空间
- 运用3-4种不同字号创造层次感，关键词使用最大字号
- 主标题字号需要比副标题和介绍大三倍以上
- 主标题提取2-3个关键词，使用特殊处理（如描边、高亮、不同颜色）

测试：列表

## 排版规范
- 仿照X/twitter的帖子格式来设计卡片
- 排版规范、美观、整齐
- 文字必须成为视觉主体，占据页面至少70%的空间
- 运用3-4种不同字号创造层次感，关键词使用最大字号
- 主标题字号需要比副标题和介绍大三倍以上
- 主标题提取2-3个关键词，使用特殊处理（如描边、高亮、不同颜色）

satori 支持的 css

以下是 Satori 支持的 CSS 属性：

布局相关

display：支持 none 和 flex，默认为 flex
position：支持 relative 和 absolute，默认为 relative
top、right、bottom、left：支持
width、height：支持
minWidth、minHeight、maxWidth、maxHeight：支持，但不支持 min-content、max-content 和 fit-content
margin 及其相关属性（marginTop、marginRight 等）：支持
gap：支持

灵活盒模型（Flex）

flexDirection：支持 column、row、row-reverse、column-reverse，默认为 row
flexWrap：支持 wrap、nowrap、wrap-reverse，默认为 wrap
flexGrow、flexShrink、flexBasis：支持，其中 flexBasis 不支持 auto
alignItems、alignContent、alignSelf、justifyContent：支持

字体与文本

fontFamily、fontSize、fontWeight、fontStyle：支持
tabSize、textAlign、textTransform、textOverflow、textDecoration、textShadow、lineHeight、letterSpacing、whiteSpace、wordBreak、textWrap：支持
WebkitTextStrokeWidth、WebkitTextStrokeColor：支持

背景

backgroundColor：支持单个值
backgroundImage：支持 linear-gradient、radial-gradient、url，单个值
backgroundPosition：支持单个值
backgroundSize：支持两个值的大小，如 10px 20%
backgroundClip：支持 border-box、text
backgroundRepeat：支持 repeat、repeat-x、repeat-y、no-repeat，默认为 repeat

边框与圆角

border 相关属性（borderWidth、borderStyle、borderColor 等）：支持 solid 和 dashed，默认为 solid
borderRadius 及其相关属性（borderTopLeftRadius 等）：支持，包括简写形式如 5px、50% / 5px

转换与效果

transform 相关属性（translate、translateX、translateY、rotate、scale、scaleX、scaleY、skew、skewX、skewY）：支持
transformOrigin：支持一值和两值语法（相对和绝对值）
objectFit：支持 contain、cover、none，默认为 none
opacity：支持
boxShadow：支持
overflow：支持 visible 和 hidden，默认为 visible
filter：支持
clipPath：支持

IMGX 更新动态贴

Tue, 11 Mar 2025 00:00:00 GMT

回顾

IMGX从2025-02-08 开始建仓库，到现在已经有一个月多一点

一开始只是为了解决写文章时配图问题，我的要求不高，但AI 生成的很难贴合实际内容。所以还不如直接用一个只有文字的图片，只需要简单排版就好了。

在解决了自己的问题后，我在 v2ex 上分享了 Github 仓库，以及现有的功能，很快收获了近 100 star

这也算是一次成功的推广吧，在只做了不到 1/4 的功能，就吸引了一批人的注意，说明这个需求还是有很多人需要的。

所以也是立马花了小一个月的业余时间，用来投入到这个项目上。

但是这一个月功能没推进多少，因为计划赶不上变化，加班一下子加了两周...

最近又回归常态后，又可以开始新的规划啦

2025-03-11 新的仓库

在升级到 0.6.0 之后，我的计划是开发一套模板录入+预设保存的机制，用于解决一大堆参数的问题，保存预设时会得到一个 4(或3)位数的预设码，这个预设码包含了使用哪个模板、使用什么默认样式等信息。

在使用时只需要携带这个预设码，再传入自己的文字内容即可获得一张图片

于是我引入了 Prisma、Mysql、Redis，以满足未来的需求。

但敲了两天代码后，发现现在的项目结构有点别扭。

前端功能很少，大部分集中在后端，但又依赖了 createSSRApp 和 renderToString，所以我再调研后决定去除这两个依赖，直接生成 VNode 来渲染出 SVG。

而且这还仅仅是 IMG 部分的功能，X 部分我还没开发，所以为了避免未来代码烂掉。

我新开了一个仓库：imgx-nitro，用于继续开发新的 Api 功能。

现有的仓库先保留（毕竟有 100 个 star），但暂时不会在这个基础上写新功能了，新的前端仓库也会基于 Vue3 再开一个。

有开发能力的小伙伴可以自行 Fork 本仓库来魔改

功能规划

我的规划是这样的：（未来）提供一个入口，可以创建自己的模板（HTML），以及编写自己模板需要的样式（props），我会根据 props，生成一个 propsSchema。

propsSchema 会在生成自己的预设时，选择模板后带出来，并且会根据propsSchema来渲染出一个表单，用于配置自己的默认样式

然后保存后就会得到一个 code，比如 1234，在使用时通过 GET imgx.zzao.club/1234/这是一段内容 即可快速拿到一个自己常用风格的图片。

当然，这套繁琐的配置只是为了方便用户从前端去使用。

真正有价值的还是在后端上。

比如和其他 Api 配合，抓取内容后输出到图片中

和插件配合，在浏览器任意网页中生成图片。

或是把本地大量的文字、或 md 文件的内容都批量转换成图片

所以我目前的想法是，先完成核心的 API。

其他功能到底是以方便普通用户使用，还是先支持开发者自建模板，还是先开发配套插件，就以实际推广后的反馈为准吧

Debian12 服务器上启动 MySQL 服务

Wed, 05 Mar 2025 10:17:23 GMT

启动方式同本地

docker compose exec mysql mysql -u root -p

创建一个数据库

CREATE DATABASE imgx CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

创建一个新用户

-- 创建用户，限制只能从特定 IP 访问（更安全）
CREATE USER 'imgx'@'%' IDENTIFIED BY 'your_strong_password!';

-- 如果需要限制特定 IP 访问（推荐）
-- CREATE USER 'prod_user'@'192.168.1.%' IDENTIFIED BY 'Strong_Password_123!';

授予最小必要权限

-- 授予特定数据库的必要权限
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, REFERENCES, LOCK TABLES 
ON imgx.* TO 'imgx'@'%';


-- 如果只需要读写权限
-- GRANT SELECT, INSERT, UPDATE, DELETE ON production_db.* TO 'prod_user'@'%';

刷新权限

FLUSH PRIVILEGES;

验证用户权限

SHOW GRANTS FOR 'imgx'@'%';

设置密码策略

-- 设置密码过期策略（90天过期）
ALTER USER 'prod_user'@'%' PASSWORD EXPIRE INTERVAL 90 DAY;

-- 设置密码重试限制和锁定时间
ALTER USER 'prod_user'@'%' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 2;

密码过期后：

用户无法执行正常操作
只能执行修改密码的操作
会收到错误提示： ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement

过期后修改密码：

-- 方式1：用户自己修改密码
ALTER USER USER() IDENTIFIED BY 'new_password';

-- 方式2：管理员帮助修改
ALTER USER 'username'@'%' IDENTIFIED BY 'new_password';

设置备份策略

-- 授予备份权限（如果需要）
GRANT SELECT, SHOW VIEW, PROCESS, TRIGGER ON production_db.* TO 'prod_user'@'%';
GRANT LOCK TABLES ON production_db.* TO 'prod_user'@'%';

测试新用户登录

docker compose exec mysql mysql -u umami -p

nuxt + prisma 编译时报错

Fri, 28 Feb 2025 00:00:00 GMT

浏览器控制台报错：

Uncaught TypeError: Failed to resolve module specifier ".prisma/client/index-browser". Relative references must start with either "/", "./", or "../".

同时页面某些功能异常，比如的 primevue 的 Button 组件 as="a" 属性失效，某些点击事件也失效。

不过这是我的问题，因为我设置了 nitro.prerender.failOnError: false 导致我忽略了很多错误信息。直到加入了 prisma 之后才暴漏出来

关于这个问题，Prisma 官方文档上有提到，但给出的不是最终解决方案

对于 pnpm 来说可以参考这个回答

nuxt.config.ts

import { createRequire } from 'module'
import { defineConfig } from 'vite'
import path from 'node:path'
import { fileURLToPath } from 'node:url'
// @ts-ignore
const __dirname = path.dirname(fileURLToPath(import.meta.url))

const { resolve } = createRequire(import.meta.url)

const prismaClient = `prisma${path.sep}client`

const prismaClientIndexBrowser = resolve('@prisma/client/index-browser').replace(`@${prismaClient}`, `.${prismaClient}`)

export default defineNuxtConfig({

vite: {
	resolve: {
      alias: {
        ".prisma/client/index-browser": path.relative(__dirname, prismaClientIndexBrowser)
      }
    }
}

})

对于 npm 来说，可以参考这个回答，（我没试）

export default defineNuxtConfig({

vite: {
	resolve: {
      alias: {
        ".prisma/client/index-browser": "./node_modules/.prisma/client/index-browser.js"
      }
    }
}

})

而这个问题，是 2022 年就存在的，今年已经是 2025 年😀

为 Nuxt 应用 MySQL 和 Redis 服务

Thu, 27 Feb 2025 10:41:22 GMT

最近开始陆续架设数据库服务，打算起一个mysql服务，不同应用之间分库。自己管自己的。

同时有一个基础服务，用于给一些单纯提供api，不提供前端界面的Nitro服务提供鉴权

这里记录一下（本地Macos下）启动MySQL服务的命令，当然Debian上也是一样的

mkdir -p mysql/{data,conf,logs,backup}

touch mysql/conf/my.cnf

[mysqld]
# 字符集
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
bind-address=127.0.0.1

# 默认认证插件
default_authentication_plugin=mysql_native_password

# 最大连接数
max_connections=1000

# 缓冲池大小
innodb_buffer_pool_size=512M

# 日志配置
slow_query_log=1
slow_query_log_file=/var/log/mysql/slow.log
long_query_time=2

[client]
default-character-set=utf8mb4

[mysql]
default-character-set=utf8mb4

禁止从远程连接数据库，如果从其他容器访问，需要加入同一个网络

services:
  mysql:
    image: mysql:8.0
    container_name: mysql_local
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: blog
    ports:
      - "3306:3306"
    volumes:
      - ./data:/var/lib/mysql
      - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf
      - ./logs:/var/log/mysql
      - ./backup:/backup
  redis:
    image: redis:7.0
    container_name: redis_local
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - ./redis_data:/data
    command: redis-server --appendonly yes
    networks:
      - mysql_internal
networks:
  mysql_internal:
    driver: bridge

chmod -R 755 mysql

docker compose up -d

语义版本控制说明 unjs/changelogen

Tue, 25 Feb 2025 00:00:00 GMT

版本号规则为：MAJOR.MINOR.PATCH

当进行不兼容API更改和升级时，升级 major 版本
以向后兼容的方式添加功能时，升级 minor 版本
修复bug时，升级 patch 版本

与之对应的三个命令（包含 github release pub ）为：

npx changelogen@latest --release --patch --push
npx changelogen@latest --release --minor --push
npx changelogen@latest --release --major --push

但是如果你的版本号从 0.0.1 开始

那 patch 和 minor 都只能升级到 0.0.2

使用 --major 可以升级到 0.1.0

注意：再次使用 --major 也只会升级到 0.2.0

因为 0.yz 版本表示不稳定的版本，所以三个语义发生了改变，不适用于常规的 1.0.0 这样的版本

如果要发布到 v1.0.0 , 可以使用 -r v1.0.0 ，此后就可以用 MAJOR.MINOR.PATCH 这个规则就行正常更新版本号了。（目前没发现有直接的命令处理v1.0.0版本的发布）

changelogen types

types: {
      feat: { title: "🚀 Enhancements", semver: "minor" },
      perf: { title: "🔥 Performance", semver: "patch" },
      fix: { title: "🩹 Fixes", semver: "patch" },
      refactor: { title: "💅 Refactors", semver: "patch" },
      docs: { title: "📖 Documentation", semver: "patch" },
      build: { title: "📦 Build", semver: "patch" },
      types: { title: "🌊 Types", semver: "patch" },
      chore: { title: "🏡 Chore" },
      examples: { title: "🏀 Examples" },
      test: { title: "✅ Tests" },
      style: { title: "🎨 Styles" },
      ci: { title: "🤖 CI" },
    }

Nuxt4 中使用 NuxtAuth 实现 Github 登录

Fri, 21 Feb 2025 00:00:00 GMT

大家都知道 Next 有个 NextAuth 非常好用，其实 Nuxt 也有配套的 Auth Module

而且 NuxtAuth 还依赖于 NextAuth，这为 Nuxt 生态提供了非常多可靠性和便利性。

NextAuth 里能用的，在 NuxtAuth 里同样支持

并且还针对Nuxt 提供了特定功能，比如登录、注销、身份验证中间件和插件等

使用 NuxtAuth 时需要注意，它包装了 next-auth@4.21.1 ，因为更高的版本中更改了包导出。

所以使用时，安装指定版本就可以了。

这里我先以 Github登录 为例演示其用法

本系列在博客站上会持续更新，直到覆盖NuxtAuth的所有用法

初始化和安装依赖

我在一个 layer 中演示其使用方法，因为这部分功能相对独立，使用的地方继承就行。

新建项目

npx nuxi init -t layer zz-auth-layer

然后来到项目根目录下，安装依赖

注：这里有两种 Provider 可选，一个是 authjs(next-auth) ，一个是 local ，所谓 local 就是你已经自己写好了一套登录逻辑，他可以帮你接管一下。

pnpm exec nuxi module add sidebase-auth
// 因为我们使用github登录，所以要安装这个包
pnpm add next-auth@4.21.1

给此项目开启 Nuxt4 的特性，Nuxt4 的目录结构更合理，更适合拓展。

export default defineNuxtConfig({
	future: {
	    compatibilityVersion: 4
	},
})

然后把根目录下的内容改造成 v4 的结构

.
├── .editorconfig
├── .env
├── .gitignore
├── .npmignore
├── .npmrc
├── .nuxtrc
├── README.md
├── app
│   ├── app.config.ts
│   ├── app.vue
│   └── components
│       └── AuthView.vue
├── nuxt.config.ts
├── package.json
├── pnpm-lock.yaml
├── server
│   ├── api
│   │   └── auth
│   └── tsconfig.json
└── tsconfig.json

组件 AuthView 里什么也没有，随便写点东西就行

配置 NuxtAuth

然后再把刚才安装的 nuxt-auth 配置一下。这里的配置内容，来源于官方文档。

export default defineNuxtConfig({
	future: {
	    compatibilityVersion: 4
	},
	auth: {
	    isEnabled: true,
	    disableServerSideAuth: false,
	    originEnvKey: 'NUXT_AUTH_ORIGIN',
	    // baseURL: 'http://localhost:3000/api/auth',
	    provider: {
	      type: 'authjs',
	      trustHost: false,
	      defaultProvider: 'github',
	      addDefaultCallbackUrl: true,
	    },
	    sessionRefresh: {
	      enablePeriodically: 1000 * 60 * 5, // 5 分钟刷新一次
	      enableOnWindowFocus: true,
	    }
	},
})

如果你此时是按照官方文档一步步的来的，那这里的 provider 就是后面配上的

然后在 app.config.ts 里增加一些信息

export default defineAppConfig({
  authLayer: {
    name: 'Hello from Auth layer (playground)',
    enabled: true,
  }
})

当这个 auth-layer 层被其他模块 extend 时，这个 authLayer 对象就会被合并过去

所以也可以直接在其他模块中使用 useAppConfig().authLayer?.enabled 来判断当前是否开启了鉴权的层

然后再来配置环境变量

刚才已经配置了一个 originEnvKey 为 NUXT_AUTH_ORIGIN ，所以需要在 .env 中增加这个环境变量

NUXT_AUTH_ORIGIN=http://localhost:3000/api/auth

此时配置的这个路径，需要我们自己定义出来，所以先新增这个接口server/api/auth/[...].ts

这个接口是一个 NuxtAuthHandler ，是从 NextAuthHandler 基础上改编来的，我们需要在这个 Handler 中定义我们的 Provider，也就是 Github

import GithubProvider from 'next-auth/providers/github'
import { NuxtAuthHandler } from '#auth'

export default NuxtAuthHandler({
  // A secret string you define, to ensure correct encryption
  secret: 'your-secret-here',
  providers: [
    // @ts-expect-error Use .default here for it to work during SSR.
    GithubProvider.default({
      clientId: 'your-client-id',
      clientSecret: 'your-client-secret'
    })
  ]
})

定义好后需要再定义一下 secret，以及Github 需要的 id 和 secret

先在 nuxt.config.ts 中定义 runtimeConfig

runtimeConfig: {
    authSecret: 'your_secret',
    authOrigin: 'your_secret',
    githubClientId: 'your_secret',
    githubClientSecret: 'your_secret',
  }

runtimeConfig 里的 authSecret 会被 .env 里的 NUXT_AUTH_SECRET 所覆盖

所以我们把真实的 authSecret 写在 .env ,然后在 git 中忽略即可

此时已经定义好了需要的四个环境变量

NUXT_AUTH_ORIGIN=http://localhost:3000/api/auth
NUXT_AUTH_SECTRET=123131231231
NUXT_GITHUB_CLIENT_ID=xxxxx
NUXT_GITHUB_CLIENT_SECRET=xxxxxx

但是 Github 的 id 和 secret 还需要自己去申请

先打开 Github ，登录后，点击头像 -> Settings -> 左侧菜单拉到最下边的 developer settings -> OAuth Apps -> New OAuth App

然后填写如下表单即可

因为请求 Github 之后，Github 需要再跳过来，需要 callback URL 需要填你本地项目的一个页面地址

等待上线后，再把此处的OAuth App 以及 .env（看部署方式而定）里配置的本地路径改为线上路径

注册后就会给你一个 id 和 secret ，把它写在 .env 里

在 Playground 中使用

配置好后，我们就可以使用 NuxtAuth 提供的 composable 来管理鉴权的逻辑了

为什么不在根目录下直接写，而是在 .playground 中写呢？

因为根目录下相当于一个独立的npm包，是要给其他项目使用的，而.playground就相当于是模拟了其他项目

所以在 layer 部分，只需要完成通用的配置、页面、接口即可，具体使用时都在 .playground 里操作

playground 里已经写好了 extends: ['..']，所以我们直接新建一个页面来测试一下如何使用 Github 登录

const {
  status,
  data,
  lastRefreshedAt,
  getCsrfToken,
  getProviders,
  getSession,
  signIn,
  signOut
} = useAuth()

<button @click="signIn('github')"> 使用 Github 登录</button>

当点击按钮时，就会跳转到 Github，授权登录后就能拿到 Github 提供的用户信息

在此之后的逻辑就和Github无关了

NuxtAuth 会帮我们做一整套的逻辑，我们只需要拿到用户信息后，和自行注册的用户做一个关联即可

status 表示当前登录状态

data 表示当前会话中的数据，这个 sessionData 也可以在 NuxtAuthHandler 的 callback 中插入一些用户信息

登出时，使用 signOut 即可

如果是使用自己写的逻辑，也就是 local Provider ，还可以配置 refreshToken 的接口等等

部署

部署时，只需要注意一下 .env 文件，因为 Nuxt 打包后不会再动态读取 .env

所以这些环境变量如何配置，和你使用的部署工具有关

比如你用的 pm2，在 ecosystem.config.cjs，就可以配置 NODE_ENV，但是我不推荐这样搞，因为如果代码要放在 github 上，就不要在任何一次提交中包含敏感的 token

除非你的 ecosystem.config.cjs 不在你的项目里，而是直接写在服务器上对应的文件夹里，每次打包时只覆盖 Nuxt 的部分

如果是用 Gitea 来自动化部署，就在 Gitea 的仓库设置中配置变量

正常情况只需要配置一次，因为正式环境没有需要经常改变的变量

以上就是如何使用 Github 的小 Demo

未完待续

一行 URL 动态生成生成封面，免费、开源、高效

Wed, 19 Feb 2025 00:00:00 GMT

背景

有时候写文章时需要上传封面图，大部分情况我只需要一种风格的图片，包含简单的文字、LOGO、强调文字等即可。

现有的各种 App 、Web 的卡片类应用都需要我打开他们的平台，然后选择合适的模板，最后还要充个会员，不然就限制我下载图片的大小，给我加个水印什么的。

此 API 可以帮助我快速在任意场景下拿到一张想要的图片。必要时可以下载，临时使用直接用链接。

并且如果是文章中配图，大部分技术平台都支持自动转存，很省心。

使用

API格式：https://imgx.zzao.club/api/img/[比例编号]/[模板编号]/[文本内容]?[参数]=xxx

如：https://imgx.zzao.club/api/img/001/001/[Nuxt4]从入门到放弃系列+点击就送屠龙宝刀

注意 color 不要带 #

比例

001：2.35:1 => 公众号
002：1:1 => 头像
003: 4:3 => ?
004: 3:4 => 小红书等
005: 16:9 => 视频封面
新比例请联系我～

模板001

此模板针对 字数不多、字号较大 的使用场景。比如文章封面、部分自媒体平台的配图。

比如高清(x2)的公众号封面配图（2.35:1）

比如小红书配图（3:4）

语法

语法	含义	说明
`[]`	强调文字	支持配置强调色，后续会支持多种强调方式
`+`	换行	文字主动换行，后续支持每行文字设置不同颜色

参数

参数	含义	参考值	说明
bgColor	背景色	292a3a-536976	目前支持两个颜色，中间用`-`分割，从左到右径向渐变
accentColor	强调色	0088a9	[xxx] 包裹的文字
color	文字颜色	ffffff	当前表示所有文字的配色，即将支持多个颜色，匹配每行文字
ratio	几倍图	1	要么 1 要么 2
center	是否居中	1	默认左对齐，居中时为整体文字都居中

技术方面

核心是 satori 和 satori-html 这两个插件。没有用到无头浏览器 puppeteer 之类的，太重，太消耗服务器资源了。

项目是 Nuxt 搭建的，通过 createSSRApp 和 renderToString，就可以拿到自己写好的 Vue 组件给 satori 渲染了，再把渲染后的 svg 转为 png, 接口直接把 png 返回

所以这个接口就类似于动态内容的 png 图片了

有条件的可以自己部署一下。

MIT

后续规划

后面的使用继续朝着极简的方向走

选取上述的参数、尺寸、模板，保存为预设码，请求时携带一个简短的code来生成图片，不需要再输入一大串参，只传递文字就可以拿到自己常用的图片。

再个就是多加几个常用的模板了，比如其他卡片应用的模板。

大家有喜欢的欢迎留言，我火速就给复刻出来。

目前还在不断的更新中。

如果你有更好的建议，或是有心仪的模板，欢迎私信我！💌

Memos Docker命令

Wed, 19 Feb 2025 00:00:00 GMT

本地打包

docker build ./ -t memoz --load

本地运行

docker run -d --name memoz -p 5230:5230 -v /memos/:/var/opt/memos memoz

docker hub发布

1️⃣打Tag

docker tag memoz gnakdogg/memoz:1.0.1

2️⃣发布

docker push gnakdogg/memoz:1.0.1

云服务器运行

docker run -d --name memoz -p 5230:5230 -v /home/memoz/:/var/opt/memos gnakdogg/memoz:latest

云服务器本地运行（因为云服务器拉不下来Docker hub

先把代码传到云服务器，然后运行 docker build 打包出镜像，然后run运行

运行到pnpm build时报内存溢出加入参数 --memory=2g

docker build ./ -t memoz --memory=2g

docker run -d --name memoz -p 5230:5230 -v /home/memoz/:/var/opt/memos memoz

Docker加速

sudo mkdir -p /etc/docker

sudo tee /etc/docker/daemon.json <<-'EOF'
{
    "registry-mirrors": [
	    "https://1js6gccw.mirror.aliyuncs.com",
        "https://docker.m.daocloud.io",
        "https://dockerproxy.com",
        "https://docker.mirrors.ustc.edu.cn",
        "https://docker.nju.edu.cn"
    ]
}
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

Docker推送到阿里云容器服务

sudo docker login --username=523748995@qq.com registry.cn-beijing.aliyuncs.com

sudo docker login --username=523748995@qq.com --password godkang75 registry.cn-beijing.aliyuncs.com

打包

docker build ./ -t memoz --load  
docker buildx build ./ -t memoz --load --platform linux/amd64 (对应阿里云ubuntu服务器)

在阿里云容器镜像服务实例中建一个命名空间如zzstudi0
2. Tag

docker tag memoz registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

Push

docker push registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

docker push --platform linux/amd64 registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

拉取

登录
拉取

docker pull registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

docker pull --platform linux/amd64 ![[成为一个前端开发者的路线.pdf]]:latest

运行

docker run -d --name memoz -p 5230:5230 -v /home/memoz/:/var/opt/memos registry.cn-beijing.aliyuncs.com/zzstudi0/memoz

docker network ： e1cb1ad4b9bc

更新版本

停止目前运行的容器
docker stop container_id
删除容器（为了避免名称冲突）
docker rm container_id

拉取指定版本

docker pull --platform linux/amd64 registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:1.1.0

然后运行指定版本

docker run -d --name memoz -p 5230:5230 -v /home/memoz/:/var/opt/memos registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:1.1.0

因为数据已经挂载到了外部，所以不用担心数据丢失

【持续更新】Nuxt 高质量资料汇总

Wed, 19 Feb 2025 00:00:00 GMT

🔥文章

Nuxt 3・Nuxt 4 の useFetch() を完全に理解する（したい）

📀视频

👍项目

shadcn-docs-nuxt : 基于 Nuxt Content 和 shadcn-vue 的文档类建站模板

使用puppeteer爬取掘金热榜

Wed, 12 Feb 2025 12:57:38 GMT

引言

又开新坑了。准备花点时间研究一下爬虫、自动化方向的技术，当然还是围绕node来展开。

我会把前端、Node相关体系的技术内容和实际需求融合，力求闭环，闭不了就当把全部干货整理成知识库。文章首发在公众号：早早集市，感兴趣的可以关注一下。

本篇是基于puppeteer这个库做的爬虫demo。

什么是Puppeteer

Puppeteer 是一个 Node 库，它提供了一个高级 API 来通过 DevTools 协议控制 Chromium 或 Chrome。Puppeteer 默认以 headless 模式运行，但是可以通过修改配置文件运行“有头”模式。

Puppeteer能做什么

生成页面 PDF。
抓取 SPA（单页应用）并生成预渲染内容（即“SSR”（服务器端渲染））。
自动提交表单，进行 UI 测试，键盘输入等。
创建一个时时更新的自动化测试环境。使用最新的 JavaScript 和浏览器功能直接在最新版本的Chrome中执行测试。
捕获网站的 timeline trace，用来帮助分析性能问题。
测试浏览器扩展。

环境准备

一是可以单独写一个js文件，从头开始写个demo，直接用node运行即可。

二是写在其他后端项目里。这里我选择写在我之前的nest的项目，方便后续灵感来了之后进一步整合。

版本：

node 18.18.2
puppeteer 21.7.0

安装

先装puppeteer

pnpm i puppeteer

如果在公司，网络不好的话，可以换个源试试

pnpm config set registry https://registry.npmmirror.com

安装完成后，我们可以写一个接口用于测试，每次请求时运行一下爬取函数。然后在service里实现爬取的逻辑。

开始编写

关于example，官网就有，很适合快速学习一下api。我仿照这个example快速开始，只不过我这里换成了掘金，因为例子里的地址因为某些原因，不方便访问。

const browser = await puppeteer.launch({
      headless: false,
      args: ['--start-fullscreen'],
    });
const page = await browser.newPage();
await page.goto('https://juejin.cn/hot/articles');

先解释一下上边几句。每个api我都附上了官方文档地址，我写代码一般就只看官方文档来写。

launch：启动一个浏览器实例，并且可以传入配置参数，如headless可以配置以无头('new')或有头模式（fasle）运行。返回值 Promise<Browser>

newPage：在 default browser context打开一个页面。返回值Promise<Page>

goto：导航到一个url。返回值Promise<HTTPResponse | null>

所以爬取数据的思路，就和自己打开浏览器进入掘金浏览一样，打开网页 ⇒ 输入地址 ⇒ 等待加载 ⇒ 加载完成 ⇒ 看到（拿到）数据 ⇒ 数据存储

因为掘金不需要登录也可以直接看到文章热榜，所以直接去找页面元素，拿到数据即可。

对于一个前端来说，去审查元素是比较简单的，如何你不是前端的话，可以用这种方式去获取元素

分析页面

F12或者右键审查，打开控制台，选中这个工具，去点击页面上的元素

![[1-img-20241119141175.png]]

在左侧点击页面上的字后，右侧控制台的元素会自动聚焦

![[2-img-20241119141155.png]]

在右侧高亮的元素上右键，可以看到复制，打开后有个复制selector，选择。因为puppeteer是使用的css selector来获取元素。

![[1-img-20241119141177.png]]

获取数据

puppeteer提供几个api可以用来获取到元素

Page.$() 相当于 document.querySelector
Page.$$() 相当于 document.querySelectorAll

这两个api的返回值分别是Promise<ElementHandle<NodeFor<Selector>> | null> 和 Promise<Array<ElementHandle<NodeFor<Selector>>>>

而ElementHandle也有获取元素的相同api

ElementHandle.$() 相当于在获取了一个元素的基础上，再获取它的子元素
ElementHandle.$$() 同理

这两个api的返回值和Page的两个api返回值相同。

获取到元素后，还需要获取元素的值。一般有两种，一种是元素的内容，一种是元素的属性值

Page.$eval('.selector', el ⇒ el.textContent) 这种方式可以直接获取到元素内容
Page.$$eval('.selector, (elements) => elements.map((el) => el.getAttribute('href')') 这种则是获取元素的属性，当然这个api是获取所有内容
ElementHandle.$eval 同理
ElementHandle.$$eval 同理

知道了这几个api之后，爬数据基本不是问题了。

继续写一下代码，粘贴一下刚才复制的selector，看看能否取到数据。

const number = await wrap.$eval('#juejin > div:nth-child(1) > div.view-container.hot-lists > main > div.hot-list-body > div.hot-list-wrap > div.hot-list > a:nth-child(1) > div > div.article-item-left > div.article-number.article-number-1', (e) => e.textContent)

可以看到复制来的selector非常长，是从页面最开始元素开始的，可以自己适当删减一下。一般只具体到它的父元素和它自己的元素就可以了。

有的时候，元素需要时间加载，比如元素基于接口渲染时，接口或者网速很慢，这个时候获取元素是获取不到的。puppeteer也有api可以等待元素加载出来

Page.waitForSelector()

比如要等待掘金热榜的文章列表被加载出来

  await page.waitForSelector('.hot-list .article-item-wrap');

然后照着葫芦画瓢，再把文章标题、作者、热度等信息也获取到

const number = await wrap.$eval(
  '.article-number',
  (el) => el.textContent,
);
const title = await wrap.$eval('.article-title', (el) => el.textContent);
const hotNumber = await wrap.$eval(
  '.article-hot .hot-number',
  (el) => el.textContent,
);
const authorName = await wrap.$eval(
  '.article-author-name-text',
  (el) => el.textContent,
);
const authorUrl = await wrap.$eval('.article-author-name', (el) =>
  el.getAttribute('href'),
);

可以在nest的控制台打印一下，看看输出的内容是否正确。

爬取完成后，可以关闭一下browser

await browser.close();

数据存储

基于学习的目的，数据可以看情况存储在本地json文件，或者数据库中，或者发送给其他服务器。

注意不要滥用数据或进行其他违法行为，目的仅仅是学习node，切记切记。

这里我选择把数据articleList存在本地json文件中。用JSON.stringify(articleList, null, 2) 按缩进为2格式化一下数据。

fs.writeFileSync(
  `./热榜-${+new Date()}.json`,
  JSON.stringify(articleList, null, 2),
);

数据处理

通过获取到的数据可以发现，很多数据没法直接存储，需要被洗一洗。比如上边文章编号，拿到数据之后有很多空格，存之前我们先处理处理。

let reg = /(
|\s)*/g;

for循环articleList
  article.number = article.number.replace(reg, '');
  article.hotNumber = article.hotNumber.replace(reg, '');

把多余的空格和去掉。

然后当前爬取的是哪个榜单，存的时候我也想记录一下，再去页面上找文章列表上方的榜单名称。

let navName = await page.$eval(
  'div.hot-list-header > div > span.hot-title > span',
  (el) => el.textContent,
);

榜单名称拿到后，也需要处理一下空格，不再赘述。

这个榜单名称是通过接口获取到然后渲染的，在点击左侧导航栏的时候就可以发现，所以要确保右侧内容被渲染完，我们再去开始爬取行为，所以可以在开头加上这两句。确保页面加载出来的时候，这两块已经被渲染完毕。

await page.waitForSelector('.hot-list .article-item-wrap');
await page.waitForSelector(
  'div.hot-list-header > div > span.hot-title > span',
);

这样就完成了对热榜-综合榜的爬取。然后再去爬其他榜单。

多页爬取

通过分析左侧的导航栏，可以在元素a标签上发现一个href，点击后，页面就会切换到对应的地址。所以我的思路是先采集全部的地址。

const navUrls = await page.$$eval(
  '.sub-nav-item-wrap .nav-item-content a',
  (elements) => elements.map((el) => el.getAttribute('href')),
);

然后把刚才写的爬取综合榜的过程，封装到一个函数里，作为爬取单页的方法。因为每个榜单的样式都是一样的。

// 伪代码
 function getPageData() {
   await 元素加载
   await 获取元素
   await 获取内容
   await 组装数据
   await 数据处理
   await 写入文件
 }

然后用一个for of 循环进行多页的爬取，注意不要用forEach，因为要保证能await

for (const url of navUrls) {
  const pageUrl = 'https://juejin.cn' + url;
  await page.goto(pageUrl);
  await this.getPageData(page);
}

然后就在项目的根目录，产生了9个json文件了，可以看一下数据爬取的有没有问题。处理过程中，主要问题是要等待页面元素加载完再拿，符合一个正常人去看网页的逻辑。

Puppeteer也提供了其他等待的方法，如：

waitForTimeout
waitForFunction
waitForRequest
waitForResponse
等等

后续我再做登录、验证码等自动化操作时再详细总结一下。

以上就是全部内容了👏

小结

这篇文章作为一个简单的小demo，记录一下研究puppeteer的开始，感觉可玩性很强。

可以用来在不适合摸鱼的办公环境，爬一下热榜然后通过webhook发到钉钉去看。或者用于签到、领这领那等重复工作。

等我发现了好玩的玩法，再写出来和大家分享。

另外最近十来天一直在梳理自己的知识库，思考自己的定位问题，对未来的做一下规划，最好和最坏的情况考虑，也在学习如何运营。可以说收获满满，能无限进步的感觉很棒。

虽然也会偶尔动摇，但总体还算坚定，后续也会稳定的输出文章！！！

我是枣把儿，欢迎关注我的公众号：早早集市，来找我玩耍🥳

【Hono】Bun竟然能这么快？搭配HonoJS的入门指南

Mon, 10 Feb 2025 00:00:00 GMT

最近我用bun+hono搭建了一个web服务，并尝试用docker打包部署。

在没有缓存的情况下，docker build 打包仅用了30s，如果是项目修改后再重新打包，更是连5s都用不了。

而这个小服务虽然只是刚起步，但已经具备了日志、响应和错误标准化返回、数据库连接（sqlite）、路由分组、环境变量配置、jwt鉴权这几项，可以说当成个人的小玩具已经够格了。

Bun和Node到底是什么关系

Bun is an all-in-one JavaScript runtime & toolkit designed for speed, complete with a
bundler, test runner, and Node.js-compatible package manager.

Bun 是一款专为提高速度而设计的一体化 JavaScript 运行时和工具包，配有捆绑器、测试运行器和与 Node.js 兼容的包管理器。

Node.js 是一个免费、开源、跨平台的 JavaScript 运行时环境。

通过他们官方的一句话介绍，可以清晰的看到，他们都是为了让JavaScript脱离浏览器环境而创造的一个运行时环境。只不过Node使用C艹编写，而Bun使用Zig。Node基于V8引擎(Goggle Chrome)，而Bun使用JavaScriptCore(Apple Safari)

以前我们用JavaScript都是和html配合写前端代码，写完后需要打开浏览器才能看到效果，而有了其他的运行时环境后，就可以像其他Python/Go语言一样直接在命令行执行JavaScript脚本，所以其功能也从操作Dom变为了操作系统级Api，如：文件IO、数据库等等。

在只有Node一家独大的时候，我们甚至可以在（某些）面试官问：「你会什么后端语言」的时候，说：「我会NodeJS」,而现在有了Deno和Bun，我岂不是会了三门后端语言？（🤫bushi

截止到当前，Node已经发布到了22.8.0，庞大的开源module支撑起了整个社群的，而他的官方包管理器npm有点让人一言难尽

于是又出现了yarn、pnpm，老外写这些东西可能真的是在解决需求，到了咱这边真的也就是给面试官多提供了一些出题思路。 而Bun本身就自带包管理器。

另外，现在要想写一个“时髦的”前端项目，还必须有一个打包器，因为在不同的运行环境中，不同的浏览器中，对JavaScript的支持标准大不相同，所以需要把新版本的JavaScript降级，或者把TypeScript转换为JavaScript。或者是把JavaScript文件大小进行压缩。

而Node生态下光打包器就有：Webpack、Rollup、Vite等等，更不要说Rust开始被大厂卷起来之后，又用Rust对以前打包速度、运行速度有上限的打包器进行重构。面试官的出题角度还在增加。
而Bun本身也是一个打包器。

另外还有测试运行器.. Vitest/Jest

所以现在可以明白，在2022年才发布的Bun究竟是想要做什么了

Hono简介

Hono🔥是一个基于 Web 标准构建的小型、简单且超快的 Web 框架。可以运行在所有JavaScript运行时，当然也包括了Bun，所以作为尝鲜，就图个鲜上加鲜。

在使用任何框架前，我都习惯先通读一遍官方文档，这大概会花费我2-4小时的时候。

在读完一遍官方文档后，如果使用过其他框架完成过类似的项目，就会大概知道这个框架哪些是自带的，哪些需要借助第三方。

如果框架本身过于精简（比如Koa），你就不得不去研究一些官方插件或是第三方插件，或者说去拜读一些开源项目，或者去找一些快速启动模板，以便自己快速上手。

Hono则是在文档里提供了很多官方的插件（Helper），无需翻看其他文档就能实现功能

搭建项目

按照官方文档开始搭建，因为我这里使用的是Bun，所以需要先下载好Bun

Macos/Linux

curl -fsSL https://bun.sh/install | bash

然后创建项目

bun create hono@latest my-app

创建项目后会有一个入口index.ts，在Bun中TS是一等公民，无需进行编译就能直接运行，所以速度非常快。

然后我们需要添加一些常用的中间件，如cors、csrf，然后给自己配置一下喜欢的端口号

import { Hono } from 'hono'
import { showRoutes } from 'hono/dev'
import { cors } from 'hono/cors'
import { csrf } from 'hono/csrf'

const app = new Hono()
// 统一的前缀
const api = app.basePath('/api')

// 预防csrf攻击
api.use(csrf())
// 所有接口设置cors， 也可以分别设置cors， 如user相关接口只允许指定ip访问
api.use('*', cors())

app.get('/', (c) => { return c.text('Hello Hono!') })
app.post('/', (c) => c.text('POST /')) 
app.put('/', (c) => c.text('PUT /')) 
app.delete('/', (c) => c.text('DELETE /'))

// 每个实例的err要自己监听
// api.onError(errorHandler)

// verbose 会显示详情信息， 如： 是否使用了中间件
// showRoutes(api, { verbose: false })

export default {
  port: Bun.env.PORT,
  fetch: app.fetch,
}

这样就完成了一个简单的服务，可以打开localhost:port，看一下是否返回了Hello Hono!

设置统一的前缀可以用basePath，设置环境变量可以在.env 、.env.development、.env.production 中配置（在bun的官方文档中），并使用Bun.env.XXXX读取。

User模块路由

只有一个接口，我们可以写在index.ts里，那如果有一堆接口呢，肯定要进行分组的

Hono中路由分组也比较简单，只要再用一次new Hono()


// user模块
const user = new Hono()

user.get('/list', (c) => c.text('List users')) // GET /user
user.get('/:id', (c) => {
  // GET /user/:id
  const id = c.req.param('id')
  return c.text('Get user: ' + id)
})
user.post('/', (c) => c.text('Create user')) // POST /user

// indext.ts
const app = new Hono()

// 使用user路由组
app.route('/user', user)

所以，要想给路由分组，只需要在src下再新建一个user文件夹，里面实现user的路由，在从index.ts里使用app.route('/user', user)就可以了。

由于我们使用了basePath，所以此时的user接口为/api/user/list 、/api/user/:id

我们在使用公司后端接口或者其他网站的开放接口接口时，经常会看到这样的结构/api/v1/user/a/b/c

在Hono中可以这样实现

user.get('/list', (c) => c.text('我是 user/list'))
v1.route('/user', user)
app.route('/v1', v1)

export default app

它会这样响应

GET /api/v1/user/list ---> `我是 user/list`

注意，如果上述代码中，route注册的顺序出错，则不会正常响应

错误捕捉

当发生一些致命错误时，为了不让服务挂掉，我们需要catch住，并且返回给前端一些友好的提示。不然我们那些年骂过的xx后端就变成了自己。

在Hono中使用也很简单，不需要自己单独写个中间件

import { HTTPException } from 'hono/http-exception'

// ...

app.onError((err, c) => {
  // 任何请求， http status 返回200， 错误码在返回体自定义
  const status = 200;
  // 记录原始的错误， 返回给前端的是友好的信息
  // TODO Logger
  const errorCode = 40001
  const errorMsg = '不是我的错，想想前端的问题！'
  if (err instanceof HTTPException) {
    errorCode = ErrorCode.UNAUTHORIZED
  }

  const response = {
    code: errorCode,
    data: null,
    message: errorMsg,
  };
  return c.json(response, status)
})

这样，在后端有任何错误的时候，我们都会以http status 200的状态码返回，并且可以在返回体中定义好固定的结果，并且返回出一个自定义的errorCode，外加一个友好的前端能看得懂的errorMsg

随着项目的复杂度增加，可以把这个handler单独拆分出去，已达到精简入口文件的目的。

比如新建一个common 文件夹，里面写一个errorHandler.ts，在index.ts中或者在user模块src/user/index.ts中，都可以分别使用app.onError() 和 user.onError()具体处理通用的或者是自定义的错误处理逻辑！

总结

这篇文章是一个入门篇，主要目的是讲述一下Node和Bun的区别，以及使用Bun+Hono的一个入门项目。

路由分组、错误捕捉这些功能很简单的就可以实现了，因为篇幅原因，我就把其他功能拆分成多篇教程了。后续教程会涉及：数据库、响应标准化、日志、jwt鉴权、docker/docker-compose打包部署等等，是一个完整闭环的小项目，代码也会开源分享出来，感兴趣的可以关注起来~

欢迎点赞催更👍

【Hono】部署篇 Docker+pm2部署

Mon, 10 Feb 2025 00:00:00 GMT

项目开发完后，要部署到服务器上才能正常使用，这里我分享一下docker和pm2两种方式的部署。

以下经验来自于**我日常的折腾中，适合入门，非企业级操作。**仅用于分享！

Docker部署

用docker的话，也算有两种运行方式。

先在本地build，然后打tag，然后push上去。

把包发布到dockerhub或你的对应的云服务商的容器镜像服务上（比如阿里云）后

一种是使用docker run 附带一些参数进行启动

另一种使用docker-compose.yml配置参数，用docker compose命令重新拉取最新的镜像并重启。

Dockerfile

这个dockerfile来自Bun的官方，然后我又加了一些自己的需求，可以做一下参考

# use the official Bun image
# see all versions at https://hub.docker.com/r/oven/bun/tags
FROM oven/bun:1 AS base
WORKDIR /usr/src/app

# install dependencies into temp directory
# this will cache them and speed up future builds
FROM base AS install
RUN mkdir -p /temp/dev
COPY package.json bun.lockb /temp/dev/
RUN cd /temp/dev && bun install --frozen-lockfile

# install with --production (exclude devDependencies)
RUN mkdir -p /temp/prod
COPY package.json bun.lockb /temp/prod/
RUN cd /temp/prod && bun install --frozen-lockfile --production

# copy node_modules from temp directory
# then copy all (non-ignored) project files into the image
FROM base AS prerelease
COPY --from=install /temp/dev/node_modules node_modules
COPY . .

# [optional] tests & build
ENV NODE_ENV=production
# RUN bun test
RUN bun run build

# copy production dependencies and source code into final image
FROM base AS release

# 一个后端node/bun服务运行,必须需要node_modules
# 以及打包后的入口
# 如果存在环境变量配置, 还需要复制环境变量配置文件
COPY --from=install /temp/prod/node_modules node_modules
COPY --from=prerelease /usr/src/app/out/index.js .
COPY --from=prerelease /usr/src/app/package.json .
COPY --from=prerelease /usr/src/app/.env .
COPY --from=prerelease /usr/src/app/.env.production .

# 此处是为了把日志和数据库持久化, 方便备份和查看
# 创建日志目录和数据库目录
RUN mkdir -p /usr/src/app/prod-logs && chmod -R 777 /usr/src/app/prod-logs
RUN mkdir -p /usr/src/app/db && chmod -R 777 /usr/src/app/db

ENV NODE_ENV=production
# run the app
USER bun
EXPOSE 4775/tcp
ENTRYPOINT [ "bun", "run", "index.js" ]

有几个dockerfile内需要注意的点：

如果你有env文件，记得也把env复制进去
如果你的日志等文件持久化了（放在了一个自定义的目录下），记得分配读写权限
记得设置ENV NODE_ENV=xxx
分阶段构建不是必须的

另外，dockerfile中用到了bun run build这个命令

要注意，bun build 需要指定 --target 为 bun

"scripts": {
    "dev": "bun run --hot src/index.ts",
    "build": "bun build src/index.ts --outdir out --target=bun"
  },

编写完dockerfile以及打包命令后，没必要去服务器验证，可以在本地验证。

docker build ./ -t your_name --load

打包后，直接在docker desktop中点击运行，输入你自定义的端口号、本地挂载路径等就可以了。

如果有错误的话，就直接在desktop看日志，解决完明显的问题后再往服务器上发。

但是如果很多类似：端口号、挂载地址、环境变量需要配置时，光在开始这一步就会感觉非常麻烦。所以还是配一个docker compose比较方便

Docker Compose

小水管服务器最好还是不要在服务器上跑**docker build** ，真是很容易就卡死。

在项目根目录下新建docker-compose配置文件

docker-compose.prod.yml

version: '3.8'
# 正式服务器打包
services:
  hono:
    container_name: 'hono'
    # 填写发布后的镜像
    image: 'xxxxxxx'
    ports:
      - '4775:4775'
    restart: on-failure
    volumes:
      - /home/db/hono:/usr/src/app/db
      - /home/log/hono:/usr/src/app/prod-logs

在配置文件内写好所有的配置，很直观。

如果是在本地的话可以再新建一个

docker-compose.dev.yml

version: '3.8'
# 开发环境测试打包
services:
  hono:
    container_name: 'hono'
    build:
      context: ./
      dockerfile: ./Dockerfile
    ports:
      - '4775:4775'
    restart: on-failure
    volumes:
      - /Users/your_name/your_dir/databases/hono-db:/usr/src/app/db
      - /Users/your_name/your_dir/databases/hono-logs:/usr/src/app/prod-logs

使用本地的dockerfile来打包验证

docker-compose up

这样就不用重复敲很多配置了。

测试没问题，可以正常运行后，就可以去发布了

发布到容器镜像服务

在各家的云服务商的后台，都可以找到各自的容器镜像服务。

因为dockhub被墙了，直接在大陆的服务器上是拉不下来dockhub的镜像的，所以要想分版本的发布，就需要用云服务商自己的容器镜像服务。

以下以阿里云为例。

sudo docker login --username=<your username> registry.cn-beijing.aliyuncs.com

注意：后面的地址registry.cn-beijing.aliyuncs.com，可以在你的阿里云后台找到

打包

打包的时候也有一个坑，就是要注意服务器的platform，在本地打包和push前就要加上参数。比如我这里是linux/amd64。（你可以先不管，等在服务器上运行时，会提示你报错信息，然后再根据提示加上platform参数重新打包发布也可以。）

docker buildx build ./ -t your_name --load --platform linux/amd64 (对应阿里云ubuntu服务器)

打Tag

打标签前，需要在阿里云控制台里，先创建好自己的命名空间，假设我这里是zzstudio1

docker tag memoz registry.cn-beijing.aliyuncs.com/zzstudi1/your_name:latest

发布

docker push --platform linux/amd64 registry.cn-beijing.aliyuncs.com/zzstudi1/your_name:latest

此时本地操作已经完成，登录到云服务器再去拉取和运行发布好的镜像

不得不说，有墙是真难受，万一有网络问题，还容易卡住。

发布成功后，再去回头看我们docker-compose.prod.yml的配置的image，就是此时发布的镜像了。

只要这个docker-compose.prod.yml文件在服务器上，就可以运行起来了。后续如果需要更新，则需要在本地重复上述的，打包、打Tag、发布流程

然后在服务器重启即可

# 先停止
docker-compose down 
docker-compose up --build -d

注意：docker compose是可以管理多个镜像的，如果你要同时使用redis、mysql、nginx等，都可以统一管理，详细使用可以看我这篇**《使用Docker Compose部署Nest应用》**，里面有详细的配置说明

小结一下

配置package.json中的build命令，注意--taget=bun

参考bun官方示例，编写Dockerfile，构建，然后把项目打上版本号，打包发布到指定平台
服务器上只装docker，服务都使用docker运行
编写多个docker-compose.*.yml文件，配置不同环境的策略，拉取指定平台指定版本的镜像
后续使用docker compose命令进行更新和重新运行

再来看一下pm2部署有什么不同

PM2部署

使用pm2运行项目，需要在服务器安装相应的环境（Bun、Pm2、Git），后续有其他服务也使用pm2进行管理就可以了。

就是不像docker似的，环境隔离起来，换服务器方便一些。

但是国内这个环境其实用docker还麻烦一些，如果能一股脑丝滑的发步到dockerhub上就会轻松很多。

所以我一般如果选择了pm2部署，就相当于在服务器上安装了一圈环境（包括Nginx），配置过一遍后，后续使用git提交代码，提交代码后再通过ssh在服务器打包和重启一下对应服务。

以下是一些基本命令，安装node、bun、nginx等，且只在Ubuntu验证过。

安装node20.x版本

curl -sL https://deb.nodesource.com/setup_20.x -o nodesource_setup.sh
sudo bash nodesource_setup.sh

使用apt安装

sudo apt install nodejs

安装完成后验证

node -v
npm -v

安装bun，先安装unzip

sudo apt install unzip

再安装bun

curl -fsSL https://bun.sh/install | bash

设置国内镜像

npm config set registry https://registry.npmmirror.com/

安装PM2

npm install pm2@latest -g

使用ecosystem.config.js （在项目根目录下新建）（内容非常简单，在官网复制就可以）

pm2 start ecosystem.config.js

pm2 stop ecosystem.config.js

pm2 reload ecosystem.config.js

pm2 restart ecosystem.config.js

pm2 delete ecosystem.config.js

安装Nginx

sudo apt install nginx

systemctl status nginx
systemctl start nginx

配置防火墙

sudo ufw allow 'Nginx HTTP'
sudo ufw allow 'Nginx HTTPS'

主配置文件：/etc/nginx/nginx.conf

站点配置文件目录：/etc/nginx/sites-available 和 /etc/nginx/sites-enabled

测试nginx配置

sudo nginx -t

重启nginx

sudo systemctl reload nginx

关于git建裸库，大家可以自行搜索相关文章，我也是按之前搜出来的一篇文章来建的，如果有懒得搜的，也可以直接私信我要教程。

最终，你的服务器上的项目文件夹内要具备：

node_modules 是的，后端项目不同于前端，也是需要node_modules才能正常运行的
package.json 用于安装和更新node_modules
env文件环境变量配置
打包且压缩后的JS文件/文件夹，如：server/index.js

此时在你的服务器环境下运行就可以了

pm2 start ecosystem.config.js

而关于重启、多实例运行等都在一个config.js里配置

启动后，验证项目是否可以被正常请求，数据库读写是否正常，日常是否在正常记录就可以了

总结

对于我来说，选择其中一种方式部署，意味着后续其他服务都用这一种方式进行部署。

如果使用了docker，那我只在服务器上把docker装好，所有服务都通过docker来打包、分版本、发布、拉取、运行、重启。

如果使用了pm2，我会在服务器上直接装一遍Node、Bun、Git、Nginx、pm2，后续通过git管理代码，通过git tag/branch或是代码内管理版本，ssh工具在服务器打包代码pm2来运行和重启。

当然有很多其他运维工具gitea、jenkins等等，我看过后感觉都不太适合我这种处于探索而非运营阶段的小水管服务器折腾。

如果真的有业务，着急搭建，我觉得花点钱找个靠谱的人弄都行，不用费这种心。

以上就是全部内容啦👏👏

【Hono】优化：提取配置项及公共函数

Mon, 10 Feb 2025 00:00:00 GMT

项目完成的七七八八了，代码也慢慢多了起来，有些基本的优化工作必须要做了。

不然等再加一些业务逻辑，就会变得非常臃肿，然后就又免不了被抛弃的命运。

写自己的玩具就是这样的，总是在不停的造玩具。

优化点1：ErrorHandler

目前的目录是这样的

.
├── Dockerfile
├── README.md
├── bun.lockb
├── bunfig.toml
├── db
│   └── zzaoclub.db
├── docker-compose.dev.yml
├── docker-compose.prod.yml
├── docker-compose.yml
├── logs
├── out
│   └── index.js
├── package.json
├── src
│   ├── common
│   ├── database
│   ├── index.ts
│   ├── salt
│   └── user
└── tsconfig.json

目前只关注src下的结构即可。

index.ts作为入口文件，加载了一些全局中间价，以及去挂载子路由，拦截全局的error。

这里能抽出去一个errorHandler，我把它放在common下。

它的功能也很简单：

拦截到错误后，把Http状态码设置为200
在控制台/日志文件中打印/记录请求时间+方式+url+原始错误信息
在上下文中使用c.get('errCode')取出在某处抛出的自定义错误，然后把自定义的错误码和错误信息或默认的错误信息返回给前端
统一返回标准如:{ code: 40001, data: xxx, msg: '1123131' }

拆好后重新引入测试，然后就已经出现了下一个优化点

优化点2：ErrorCode

刚才拆处errorHandler后，发现会取一些默认的错误信息，以及有一套自定义的错误嘛。

所以要提前定义好一套，不然随手就写个40001、40002、40003，时间长了鬼知道这是什么意思。

所以再从common下新建一个errorCode.ts ，我只是举个例子，错误码和信息要自己看着来。

export const ErrorCode = {
  PERMISSION_DENIED: 40001, // 权限问题
  VALIDATION_ERROR: 40002, // 参数问题
  UNAUTHORIZED: 40003, // 未登录
  LOGIN_EXPIRED: 40004, // 登录已过期
  NOT_FOUND: 40005, // 不存在的接口
  INTERNAL_SERVER_ERROR: 50000, // 服务器内部错误
  UNKOWN_ERROR: 50001 // 未知错误
}

export const ErrorCodeMsg = {
  [ErrorCode.PERMISSION_DENIED]: '权限问题',
  [ErrorCode.VALIDATION_ERROR]: '参数问题',
  [ErrorCode.UNAUTHORIZED]: '未登录',
  [ErrorCode.LOGIN_EXPIRED]: '登录已过期',
  [ErrorCode.NOT_FOUND]: '不存在的接口',
  [ErrorCode.INTERNAL_SERVER_ERROR]: '服务器内部错误',
  [ErrorCode.UNKOWN_ERROR]: '未知错误'
}

这样在某个路由抛出错误时，应该是这样的

 c.set('errCode', ErrorCode.UNAUTHORIZED)

然后接下来再去看看已有逻辑里，哪里需要抛出错误，把这些自定义的错误码给用上。

优化点3：JWT相关

刚才在替换错误码时，发现JWT和Zod的相关逻辑里需要抛出一些异常。而有了两个模块后，也会发现他们有一些重复代码。

比如user中的jwt中间件和salt模块中是一样的，没必要写两份，可以把jwt中间件的逻辑抽出，放在index.ts中，目前来看，jwt只是校验一下用户有没有登录，以及跳过一些路由白名单。

所以可以先把jwt逻辑抽出来，以下是一个参考

const JWT_SECRET = Bun.env.JWT_SECRET || ''
const jwtMiddware = jwt({
  secret: JWT_SECRET,
})

salt.use('/*', async (c, next) => {
  if (NoAuthPaths.includes(c.req.path)) {
    await next();
    return;
  }
  await jwtMiddware(c, async () => {
    const user = c.get('jwtPayload')
    
    if (!user) {
      c.set('errMsg', '用户未登录')
      c.set('errCode', ErrorCode.UNAUTHORIZED)
      throw new HTTPException(401)
    }

    if (user.id !== 1) {
      c.set('errMsg', '用户无权限')
      c.set('errCode', ErrorCode.PERMISSION_DENIED)
      throw new HTTPException(401)
    }
    await next()
  })

})

把后面函数单独抽离出去即可，同时我在每个模块下如src/user、src/salt下再放一个common.ts，把路由白名单（NoAuthPaths）放进去，每个模块在使用jwt中间件时，再把这个白名单传进去。

优化点4：Zod相关

看到路由的参数校验那一串，就知道不得不优化一下，因为不可能每个接口直接写那么一大串schame。

抽离分两部分，一部分是validator函数，一部分是schame的定义。

先来validator，在common下再新建个validator.ts，封装一个zvalidator函数，传参就按zValidator需要什么就行，主要是为了抛出错误。

以下也只是个示例：

import { zValidator } from "@hono/zod-validator"
import { Context, Next } from "hono"
import { ErrorCode, ErrorCodeMsg } from "./errorCode";
import { HTTPException } from "hono/http-exception";
// 自定义校验, 在校验失败时抛出异常, 由errorHanlder统一处理
export const zvalidator = (source: any, schema: any) => {
  return zValidator(source, schema, (result, c: Context) => {
    if (!result.success) {
      const errMsg = result.error.errors.map((e: any) => `field:${e.path[0]} - ${e.message}`).join(', ')
      c.set('errMsg', errMsg)
      c.set('errCode', ErrorCode.VALIDATION_ERROR)
      throw new HTTPException(400, { message: errMsg })
    }
  })
};

然后再把schame抽出去，在模块目录下新建一个schame.ts，因为这块不是公共的，是每个模块每个接口都有可能不一样。就类似路由白名单也样，我也没把它放在common下，而是都放在了模块目录下。

// 对象
export const userSchema = z.object({
  name: z.string(),
  desc: z.string().optional().default(''),
  desc2: z.string().default(''),
})

// 列表
export const usersSchema = z.array(userSchema)

// 修改
export const sauceUpdateSchema = userSchema.extend({
  id: z.string().min(1)
})

我目前用的语法就这几个，一个普通对象，一个数据对象，一个继承方法用来抽离一些公共的schame。

抽出一部分逻辑后，目录现在是这样的，清晰了很多，目前除了要完善具体逻辑，应该没有目录上的改动了

.
├── Dockerfile
├── README.md
├── bun.lockb
├── bunfig.toml
├── db
│   └── zzaoclub.db
├── docker-compose.dev.yml
├── docker-compose.prod.yml
├── docker-compose.yml
├── logs
├── out
│   └── index.js
├── package.json
├── src
│   ├── common
│   │   ├── errorCode.ts
│   │   ├── logger.ts
│   │   ├── responseFormatter.ts
│   │   └── validator.ts
│   ├── database
│   │   └── sqlite.ts
│   ├── index.ts
│   ├── salt
│   │   ├── config.ts
│   │   ├── crud.ts
│   │   ├── index.ts
│   │   ├── readme.md
│   │   └── schema.ts
│   └── user
│       ├── crud.ts
│       ├── index.ts
│       └── schema.ts
└── tsconfig.json

优化点5： Env

在开发项目时，可能会随手写一些变量，这些变量在开发和正式环境下是肯定不一样的，所以我要把它放在.env中，以便后续部署后也能正常使用。

最典型的就是winston，本地日志文件的路径和正式服务器上分别配置好

.env.production

LOG_DIR=/usr/src/app/prod-logs

.env.development

LOG_DIR=logs2/

然后在common/logger.ts中替换成对应的env变量

const LOG_DIR = Bun.env.LOG_DIR || 'logs/';
...
transports: [
    new DailyRotateFile({
            filename: path.join(LOG_DIR, 'info-%DATE%.log'),
  ...

后面等开始部署时，再来验证配置是否生效。

然后index.ts中的port，也可以配置一下，开发和正式没必要一样，尤其是选择开源的话。

export default {
  port: Bun.env.PORT,
  fetch: app.fetch,
}

然后就是JWT的secret

const JWT_SECRET = Bun.env.JWT_SECRET || '1234567'

修改并替换好后，还要记得在.gitignore中把.env.production加上，就不要提交到仓库里去了。

还有日志文件，也没必要提交上去

总结

虽然代码没多少，但是基本的封装和目录划分还是要提前思考一下。

总体的思路就是：

一、整个项目公用的提取到src/common，每个模块公用的放在src/模块/下就近管理，不出现重复代码

二、代码中不要出现不清不楚的常量，每个常量要定义好语意化的枚举、Map等变量引入的方式使用

三、区分环境的配置进一步提取到env文件或其他配置中心服务

ok，就这样。以后的问题碰到再解决即可（比如现在TS用了很多any）。

【Hono】Gitea+Bun+Hono+Pm2 自动化部署后记

Mon, 10 Feb 2025 00:00:00 GMT

本文记录一下bun项目在使用pm2部署时产生的一点问题。

部署流程：使用Gitea自建git仓库，编写workflow，on[push]，自动拉取代码=>下载依赖=>打包=>移动到目标文件夹=>启动/重启 pm2 stop/start ecosystem.config.cjs

云服务器（新加坡）：debian 12 2h4g
bun: 1.1.31
pm2: 5.4.2

这是一个4G内存的机器，所以我上了gitea，利用gitea的act_runner自动部署。

2G的服务器我实测打包Nuxt项目会爆内存，刚好峰值内存要吃2G出头。

项目本身使用honojs，有几个简单接口，只有登录注册业务。因为已经用其他项目把act_runner调通了，所以这个项目也很顺利的运行成功。整个gitea actions运行时间在1s左右

但是pm2启动后显示error，没有错误日志!!

actions是已经成功跑完的，所以生产环境需要的文件已经被移动到了目标文件夹内。

尝试在项目根目录直接使用bun run index.js后，发现有打不开.env.production里配置的目录的情况，原来是没正确加载上NODE_ENV

于是又查阅了一番pm2文档、bun文档，发现需要给pm2 start加上--env production参数

pm2 start ecosystem.config.cjs --env production

加上后，重新提交代码，自动部署，发现还是一样，显示error但没有日志

再次在项目根目录直接使用NODE_ENV=production bun run index.js，发现可以正常运行，那估计就是pm2有什么问题影响了，但单看配置文件是没有写错的，还是不知道什么原因无法用pm2启动

于是又不用配置文件启动，尝试直接pm2 start index.js --interpreter bun 跑一下试试，这时候发现可以了，而且mode很明显是fork，而刚才我配置ecosystem.config.js时用的是cluster。

bun官网也只是提了一下要配置一下interpreter为~/.bun/bin/bun。无奈只能先这样处理，等后续解决后再来水一篇！

👇下面是配置参考

module.exports = {
  apps: [
    {
      name: 'your_app_name',
      port: '5577',
      // 运行bun项目时，先设置为fork模式
      exec_mode: 'fork',
      // instances: 'max',
      script: 'index.js',
      interpreter: '/root/.bun/bin/bun',
      env: {
        NODE_ENV: 'production'
      },
      env_production: {
        NODE_ENV: 'production'
      }
    }
  ]
}

.gitea/workflow/build.yaml 这个完全和github一致，熟悉github actions的可以略过了

name: Gitea Actions Demo
run-name: ${{ gitea.actor }} is testing out Gitea Actions  
on: [push]
jobs:
  Explore-Gitea-Actions:
    runs-on: debian
    steps:
      - run: echo "  The job was automatically triggered by a ${{ gitea.event_name }} event."
      - run: echo "  This job is now running on a ${{ runner.os }} server hosted by Gitea!"
      - run: echo "  The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
      # 把代码checkout到一个临时的文件夹中
      - name: Check out repository code
        uses: actions/checkout@v3
      # 下载依赖，因为我要在服务器打包代码
      - name: Install dependencies
        run: bun install
      # 打包代码
      - name: Build Project
        run: npm run build
      # 打包后的代码，移动到指定的文件夹内
      # 为了测试配置文件，我把两个配置文件都copy过去了，实际只用到了.env.production
      - name: Copy Files
        run: |
          mkdir -p /root/a/b
          cp -R out/* /root/a/b/
          cp -R ecosystem.config.cjs /root/a/b/ecosystem.config.cjs
          cp -R package.json /root/a/b/package.json
          cp -R .env.production /root/a/b/.env.production
          cp -R .env /root/a/b/.env
      # 下载依赖
      - name: Install dependencies
        run: |
          cd /root/a/b
          bun install
     # 使用pm2启动项目 --env production
      - name: Deploy to production2
        run: |
          cd /root/a/b
          pm2 stop ecosystem.config.cjs
          pm2 start ecosystem.config.cjs --env production
      - run: echo "  The ${{ gitea.repository }} repository has been cloned to the runner."
      - run: echo " ️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls ${{ gitea.workspace }}          
      - run: echo "  This job's status is ${{ job.status }}."

【Hono】完善：参数校验+响应标准化

Mon, 10 Feb 2025 00:00:00 GMT

上一章我们完成了基于Hono的web项目的搭建工作，并实现了路由分组，错误处理等逻辑。

这一章来继续完善项目，让它变的健壮起来💪。

参数校验

平时我们写前端的时候，最希望后端把校验做的越全越好，提示信息越详细越友好越好，那现在就轮到我们自己实现后端了。

hono 官方比较推荐的是zod作为校验库，并提供了@hono/zod-validator，封装了一下中间件，让我们可以直接放在请求路径后面用。

并且官方并不推荐路由第二个参数再写个 handler 封装，然后再传进来

这种写法在其他node框架中十分常见，如Koa、Nest

// 🙁
// A RoR-like Controller
const booksList = (c: Context) => {
  return c.json('list books')
}

app.get('/books', booksList)

下面是官方推荐的写法

// 😃
app.get('/books/:id', (c) => {
  const id = c.req.param('id') // Can infer the path param
  return c.json(`get ${id}`)
})

上述写法的原因和类型有关，如果不写复杂的泛型，就无法在Controller中推断出路径参数。

这样也好，在业务真正复杂前来之前，保持程序的简洁。

回到参数校验部分，@hono/zod-validator使用比较简单，就是在路由第二个参数插入这个中间件

import { zValidator } from '@hono/zod-validator'

const route = app.post(
  '/posts',
  zValidator(
    'form',
    z.object({
      body: z.string(),
    })
  ),
  (c) => {
    const validated = c.req.valid('form')
    // ... use your validated data
  }
)

如果需要多个验证器

app.post(
  '/posts/:id',
  validator('param', ...),
  validator('query', ...),
  validator('json', ...),
  (c) => {
    //...
  }

加入校验后，来使用 apifox 测试一下，可以看到 zod 返回如下的校验结果

{
    "success": false,
    "error": {
        "issues": [
            {
                "code": "invalid_type",
                "expected": "number",
                "received": "undefined",
                "path": [
                    "page"
                ],
                "message": "Required"
            },
            {
                "code": "invalid_type",
                "expected": "number",
                "received": "undefined",
                "path": [
                    "size"
                ],
                "message": "Required"
            }
        ],
        "name": "ZodError"
    },
    "_error": {
        "issues": [
            {
                "code": "invalid_type",
                "expected": "number",
                "received": "undefined",
                "path": [
                    "page"
                ],
                "message": "Required"
            },
            {
                "code": "invalid_type",
                "expected": "number",
                "received": "undefined",
                "path": [
                    "size"
                ],
                "message": "Required"
            }
        ],
        "name": "ZodError"
    }
}

可以看到返回了详细的校验信息，但美中不足的就是这个中间件会以自己的结构直接返回给前端，这显然不合理，我们要的是标准化的返回。

所以这个中间件还可以传入第三个参数作为回调，然后自己手动抛出错误

zValidator(source, schema, (result, c: Context) => {
    if (!result.success) {
      const errMsg = result.error.errors.map((e: any) => `field:${e.path[0]} - ${e.message}`).join(', ')
      throw new HTTPException(400, { message: errMsg })
    }
  })

抛出错误后我们在 errorHandler 中就可以接收到错误信息了，再经过处理一下，返回固定的格式（此处代码只是演示）

export const errorHandler = async (err: Error, c: Context) => {
  // 错误处理
  const errorMsg = "出错了"
  if (err instanceof HTTPException) {
     return err.getResponse()
  }
  const response = {
    code: 50001,
    data: null,
    message: errorMsg,
  };
  return c.json(response, status)
}

现在errorHandler 已经处理了好几种错误：jwt、zod、系统错误等等

我们总不能每次想起一种错误来，就来这个写个 if else 处理一下，所以我们可以定义一组通用的 errorCode和errorMsg map结构，并且让每个抛出错误的中间件把相关信息写入到上下文中，由于上下文仅在当前的请求链路有效，所以也不用担心污染。

在上下文中传递信息

app.use(async (c, next) => {
  c.set('message', 'Hono is cool!!')
  await next()
})

app.get('/', (c) => {
  const message = c.get('message')
  return c.text(`The message is "${message}"`)
})

在errorHandler中就可以这样接受错误信息

export const errorHandler = async (err: Error, c: Context) => {
  // 错误处理
  // 任何请求， http status 返回200， 错误码在返回体自定义
  const status = 200;
  // TODO 记录原始的错误， 返回给前端的是友好的信息
  // 从上下文拿错误码, 优先取自定义的msg => 错误码对应信息  => 未知错误
  let errorCode = c.get('errCode')
  if (!errorCode) {
    // 抛出了HTTPException， 视为权限不错
    if (err instanceof HTTPException) {
      errorCode = ErrorCode.UNAUTHORIZED
    }
  }
  let errorMsg = c.get('errMsg') || ErrorCodeMsg[errorCode] || ErrorCodeMsg[ErrorCode.UNKOWN_ERROR]

  const response = {
    code: errorCode || ErrorCode.UNKOWN_ERROR,
    data: null,
    message: errorMsg,
  };
  return c.json(response, status)
}

这样每个抛出错误的中间价，可以写入详细的错误信息，而一组自定义的 errorcode 也可以应付更多的业务场景，如果增加了一个场景，我们**只需要去map结构中再加一组key-value，**如果没有自定义错误信息，则使用 code 对应的默认 msg 进行返回。

抛出错误时，自定义错误信息。这一块可以进行一个封装，因为每个接口都要写这么一大串，明显不合理，所以提取到公共的文件夹下面去。

// 封装自定义的zvalidator
export const zvalidator = (source: any, schema: any) => {
  return zValidator(source, schema, (result, c: Context) => {
    if (!result.success) {
      const errMsg = result.error.errors.map((e: any) => `field:${e.path[0]} - ${e.message}`).join(', ')
      c.set('errMsg', errMsg)
      c.set('errCode', ErrorCode.VALIDATION_ERROR)
      throw new HTTPException(400, { message: errMsg })
    }
  })
};

响应标准化

完成了参数的校验，并顺着问题一步步封装了关于错误信息的处理。接下来就开始让接口能正常的返回数据了。

然而虽然错误信息我们已经标准化，但正常的返回不方便用中间件直接去拦截。

原因是 c.json 直接就是一个 Response，虽然会走到我们的全局中间件里去，但没法再二次加工 Response 了，官方给出了一个例子，可以把 res 设置为undefined，然后重新 new Response

我觉得破坏性太大了，也不优雅，所以暂时没找到类似 nest 那样，在 response 之后拦截的钩子。

但这都是小问题，以后有看到更好的处理方式再进行优化就行，这里我们就简单的封装一下对象，塞到 c.json 中返回就好了

export const standardRes = (data: any) => {
  return {
    code: 200,
    data,
    message: 'success'
  }
}
// case
user.post("/list", zvalidator('json', pageSchema), (c) => {
  const params = c.req.valid('json')
  // do something
  const list = userModal.getList(params)
  return c.json(standardRes(list))
})

有细节没优化不是什么大问题，重要的是把流程先打通

JWT TOKEN

现在路由也分组了，错误也捕捉了，正常响应也处理了，参数也进行了校验。那就到了接口权限这一步上。

虽然你的网站可能只需要给用户展示信息，但有时也需要一个平台去写入数据，修改数据或删除数据才行。

这种敏感操作不可能让普通用户去做，一般都是管理员，甚至只有自己去操作，所以才需要一个登录操作，以便确认用户身份。

而登录操作，是为了拿到一个令牌，好让这个用户在后续的操作中畅通无阻。这里我们是用 jwt 来给用户发放令牌，jwt 的使用 hono 官方也有说明。

具体流程就是：用户登录 - 拿到令牌 - 后续操作携带令牌 - 校验令牌是否有效 - 有效就允许用户继续操作 - 无效则返回相关错误信息 - 前端提示用户或引导进入登录页

而我们的用户有很多个，所以一般 jwt 的 payload 会和用户信息挂钩，每个登录的用户通过 sign 拿到一个 token，并在后续操作中把 token 放在 header 中，接口则是在中间件中通过 c.get('jwtPayload')拿到令牌中包含的用户信息，去进行相关的校验。比如数据库中有无此用户，此用户的权限等级够不够等情况，如果校验不通过就 throw new HTTPException(code)，并把 errorMsg 写入上下文让 errorHanlder 去处理。校验通过则继续后续的业务逻辑。

这里我演示一个登录接口，来生成token

user.post("/login", async (c) => {
  const user = { id: 1, name: 'zzao.club' };  // 假设这是经过验证的用户信息
  const payload = {
    id: user.id,
    exp: Math.floor(Date.now() / 1000) + 60 * 60, // 检查令牌不会过期 in 60 minutes
  }
  const token = await sign(payload, JWT_SECRET);
  console.log(`token`, token)
  return c.json(standardRes(token));
})

其中如果 exp在payload中，则jwt会检查token是否过期了，payload还可以传入其他参数：

nbf : 检查token在指定时间之前没有被使用
iat : 检查token没有使用未来的时间进行签发。意思是，设置一个未来时间使自己的token一直有效（I guess）（The token is checked to ensure it is not issued in the future.）

这里我只使用了exp设置token 60min后过期就可以了。

当然，还有一种需求。

作为一个用户，我每天都在你的网站上使用，不想隔几天登录就失效，还要重新登录。

所以我们还可以再设置 refresh token，这个 token 专门用来更新 access token （也就是上边例子里的token）的有效期。比如 refresh token 3 天过期，access token 7 天过期，在 refresh token 过期时，前端就调用一个刷新 token 的接口去生成一个新的access token ，前端拿到新token后再在之后的请求中带上新的token即可。

这样用户登录过一次后，只要平时在一直使用，就可以一直保持登录状态。

下面是一个为user模块使用jwt中间件的中间件case

import { jwt } from 'hono/jwt'

const jwtMiddware = jwt({
  secret: 'your secret!!!!',
})

user.use('/*', async (c, next) => {
  // 检查当前请求路径是否在排除列表中
  if (NoAuthPaths.includes(c.req.path)) {
    await next();
    return;
  }
  // 如果不在排除列表中，则进行JWT验证
  await jwtMiddware(c, async () => {
    const user = c.get('jwtPayload')
    // 获取payload中的user信息
    // 这些信息由登录接口提供
    if (!user) {
      c.set('errMsg', '用户未登录')
      c.set('errCode', ErrorCode.UNAUTHORIZED)
      throw new HTTPException(401)
    }

    if (user.id !== 1) {
      c.set('errMsg', '用户无权限')
      c.set('errCode', ErrorCode.PERMISSION_DENIED)
      throw new HTTPException(401)
    }

    await next()
  })

})

其中 const user = c.get('jwtPayload') 这个写法也是官方文档中的写法，也是把jwtPayload写入到了上下文中，然后在后续的中间件中就可以拿到这个payload。

每个模块的中间件处理逻辑可能相同也可能不同，后续我们再看情况，把它抽离到根路由下或者写成一个单独的中间件，需要的模块自己去引入。

总结

目前对项目模块进行了分组，如：用户，商品等等。每个模块可以写自己的errorHandler，也可以去设置自定义中间件。而像 csrf cors等共同的中间件则放在根路由下

针对接口能否被请求，使用了hono/jwt，并为了让某些接口跳过校验以及不通过时返回自定义的错误信息，又封装装了一层。

接口可以请求之后，来到参数校验的中间件@hono/zod-validator，由于每个接口schema可能比较多，以及为了让errorHandler来处理zod校验不通过的情况，又自定义了一个中间件在内部抛出错误。schema则是被提取到公共的文件夹（如common）下

请求成功时，使用一个standardRes函数简单包装一下，统一返回值。

请求失败时，在上下文中使用c.set/get注入错误信息，在errorHandler中间件中取出错误信息，并返回和成功时一致的json结构。

这样看起来就又完善了一些~~

下一章为日志、数据库操作、配置文件相关逻辑

**欢迎点赞催更(¯▽¯)**👍

【Hono】完善：使用sqlite数据库及基于winston的日志持久化

Mon, 10 Feb 2025 00:00:00 GMT

前面两章完成了项目搭建、路由分组、参数校验、响应标准化、错误处理等功能点。

这一章来继续完善项目，并且为整个项目画一个图辅助理解。

使用Bun作为数据库

在hono项目中使用sqlite作为数据库十分简单，因为bun自带了sqlite模块！

用的时候都不需要去install了，直接在文件中引入即可

import { Database } from 'bun:sqlite';

然后在简单翻阅文档后，发现可用的api似乎也比较简单，所以简单封装一下

// src/database/sqlite.ts

const sqlite: Database = new Database("db/zzaoclub.db", { create: true, strict: true });

// 查询单条数据
export const query = (sql: SQL) => {
  return sqlite.query(sql);
};

// 查询列表数据
export const queryAll = (sql: SQL) => {
  return sqlite.query(sql).all();
};

// 执行新增、删除、修改等不需要返回值的操作
export const run = (sql: SQL, params: any[] = []) => {
  return sqlite.run(sql, params);
};
// run 会返回以下
// {
//   lastInsertRowid: 0,
//   changes: 0,
// }
export default sqlite;

简简单单的，甚至觉得哪里不对劲。

然后使用时，再去具体模块内定义查询的SQL语句。

由于也没有看到有什么推荐的orm，这里我决定体验一下原生SQL来写好了

// src/user/crud.ts

import { queryAll } from '../database/sqlite';

// 比如一个简单的用户列表查询
export function getUserList() {
  return queryAll('SELECT * FROM users');
}

在路由处使用

// src/user/index.ts

user.post("/list", zvalidator('json', userSchema), (c) => {
  // 校验后的params
  const params = c.req.valid('json')
  const users = userModal.getUserList()
  return c.json({ data: users })
})

然后就结束了。🤔

或者可以像bun的文档中这样

const query = db.query("SELECT * FROM foo WHERE bar = $bar");
const results = query.all({
  $bar: "bar",
});

我觉得倒不如直接把一条语句写好传进来了。

so，只要再跟着AI学习一下基础的CRUD操作就可以了，我觉得对于实现简单应用来说不难。

当然，表结构不会自动创建，我们还是要写一个sql文件，比如init.sql，让程序在初始化时运行。

或者借助一些sqlite工具来生成SQL语句

--- 用户表
CREATE TABLE IF NOT EXISTS user (
	"id"	INTEGER NOT NULL UNIQUE,
	"username"	TEXT NOT NULL DEFAULT '',
	"nickname"	TEXT NOT NULL DEFAULT '',
	"phone"	TEXT NOT NULL DEFAULT '',
	"role"	TEXT NOT NULL CHECK(role in ('admin','user','vendor')),
	"password_hash"	TEXT NOT NULL DEFAULT '',
	"avatar_url"	TEXT NOT NULL DEFAULT '',
	PRIMARY KEY("id" AUTOINCREMENT)
);

再打通上述接口后，就可以拿Apifox等工具再去请求一下，看看能否拿到自己插入的数据。

具体的SQL语句我就不展示了，一般让AI写出来一试，也不会有什么问题。

日志系统

日志我们使用winston这个库来实现，也是不管用什么框架都可以使用的

首先install，这里需要搭配另一个插件，实现日志按天分割，以及配置日志保存方式、保存时长等等

bun add winston winston-daily-rotate-file

使用winston.createLogger()来创建一个中间件，然后配置两个输出的log文件，一个用来存储日常所有的日志，一个单独存储错误日志，且都是按天分割文件。

// LOG_DIR 需要自行配置

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.colorize(), // 添加颜色化格式化器
    winston.format.timestamp({
      format: 'YYYY-MM-DD HH:mm:ss'
    }), // 时间日期格式
    winston.format.printf(({ timestamp, level, message }: any) => {
      return `${timestamp} ${level}: ${message}`;
    }) // 打印格式
  ),
  transports: [
    new DailyRotateFile({
      level: 'info',
      filename: path.join(LOG_DIR, 'info-%DATE%.log'),
      datePattern: 'YYYY-MM-DD',
      zippedArchive: true,
      maxSize: '10m', // 文件大小
      maxFiles: '7d', // 保留日志文件7天
      format: winston.format.combine(
        winston.format.uncolorize(), // 去除颜色 不去除无法toUpperCase
        winston.format.printf(({ timestamp, level, message }: any) => {
          return `${timestamp} ${level.toUpperCase()}: ${message}`;
        })
      ),
    }),
    // 错误日志文件传输配置, 生产环境建议放在别的目录下, 和开发环境区分开
    new DailyRotateFile({
      level: 'error',
      filename: path.join(LOG_DIR, 'err-%DATE%.log'),
      datePattern: 'YYYY-MM-DD',
      zippedArchive: true,
      maxSize: '10m',
      maxFiles: '30d', // 保留错误日志文件30天
      format: winston.format.combine(
        winston.format.uncolorize(), // 去除颜色
        winston.format.printf(({ timestamp, level, message }: any) => {
          return `${timestamp} ${level.toUpperCase()}: ${message}`;
        })
      ),
    })
  ]
});

配置项很好理解，也可以很方便的实验，所以就不过多赘述了。

然后去添加一个全局的中间价，打印一下请求信息

// src/index.ts
// 这里myLogger就是winston创建的logger
api.use('*', async (c, next) => {
  const start = Date.now();
  await next();
  const ms = Date.now() - start;
  // 使用 winston 创建的 logger 记录每个请求的详细信息
  myLogger.info(`[${c.req.method}] ${c.req.path} - ${c.res.status} - ${ms}ms`);
})

然后再去使用浏览器或Apifox尝试请求一下，看看效果

2024-09-19 16:35:37 error: [GET] http://localhost:4775/api/user - no authorization included in request
2024-09-19 16:35:37 info: [GET] /api/user - 200 - 6ms

能看到正常打印信息就可以了

然后再检查一下我们配置好的保存日志文件的目录下（注意目录要创建好，并且程序具备读写权限），会生成出 err-2024-09-10.log 以及info-2024-09-10.log两个日志文件即可。

总结

这一章主要是对项目的补充，借助bun:sqlite可以很方便的使用sqlite数据库，而且不像Mysql那样还需要安装和启动数据库服务，省时省力，开箱即用。

针对项目运行中方便排查可能出现的问题，加入了winston来让日志写入到文件中，同时日志文件可以限制大小，限制保存时长，按日期分割等等。

目前整个项目的结构已经比较清晰了，最后的环境配置放在下一节的优化里来一起写，最后再补一个图来梳理一下整个流程

使用 Layers 扩展你的 Nuxt4 应用

Mon, 10 Feb 2025 00:00:00 GMT

面对一个臃肿的页面或项目，你会如何简化重构、扩展它？

当单个 Vue 文件中界面/业务足够多时，通常我们会把它拆分成多个 components 或 composables 来引入，以此来减少此文件复杂度和增加可维护性。

当一个项目的界面/业务逻辑足够多时，我们会在全局抽离一部分组件和逻辑，在不同的业务逻辑中复用。或者把和业务解耦的组件或工具函数甚至固定业务逻辑发布为 npm 包来使用，进一步减少项目中的代码复杂度。

当存在多个项目，而项目之间又存在相同业务时，我们可能会把具有完整功能的一部分逻辑抽离成独立的项目。同时多个项目的 UI组件库和通用逻辑层也发布为 npm 包，供所有项目下载使用以保持统一的视觉效果和减少重复代码的编写。这样当一个新的项目出现，需要利用其他已有的业务逻辑或者是完全复用其他项目的页面和功能时，我们可以使用 iframe 或沙箱来加载这个独立的项目。这样多团队可以维护自己的业务项目，同时又能避免开发重复的功能。

那么在 Nuxt 里的如何优雅的解决这些问题呢？

除了上述的任何框架的项目都能操作的方式，Nuxt 还有自己独特的扩展方式：Layer

Layer 可以解决什么问题

Layer 几乎就是一个完整的 Nuxt 项目。

开发了一个 Layer，意味着 Layer 中的组件、函数、接口、依赖包等都会继承了此 Layer 的项目应用。

它不是一个最新版本才有的功能，但官方的文档的介绍十分简单，可能是因为它还在不断的完善中，官方也不希望你用于生产环境中。

一个 Nuxt4 应用的最简目录结构是这样的：


├── README.md

├── **app**

│   ├── app.config.ts

│   ├── app.vue

│   └── **pages**

│       └── index.vue

├── nuxt.config.ts

├── package.json

├── pnpm-lock.yaml

├── **public**

│   ├── favicon.ico

│   └── robots.txt

├── **server**

│   └── tsconfig.json

└── tsconfig.json

而一个 Layer 模板的目录结构是这样的：

├── .editorconfig

├── .gitignore

├── .npmrc

├── .nuxtrc

├── .playground

│   ├── app.config.ts

│   └── nuxt.config.ts

├── README.md

├── app.config.ts

├── app.vue

├── components

│   └── HelloWorld.vue

├── eslint.config.js

├── nuxt.config.ts

├── package.json

├── pnpm-lock.yaml

└── tsconfig.json

可以看到，会用 Nuxt 就会写 Layer，无需引入其他负担即可扩展。

开发一个 Nuxt4 应用时，我们会在 app 目录下开发各种 pages、components、composables、utils，会在 app.config.ts 里设置一些全局配置项。

需要接口支持时，可以在 server 目录下借助 Nitro 的生态来完成后端服务。

但是当项目开始变得臃肿时，Layer 可以发挥什么作用呢。

场景1：我的网站有一个登录注册权限校验相关的逻辑，这肯定会涉及到一些页面、组件、结构，比如登录页、注册页、登录按钮、登录注册接口等等。

一开始我没打算把它们抽离出去，因为网站还很小，并且只有一个。但是我很清楚这一部分功能和组件是可以被复用的。只要我再创建一个 nuxt 应用，我可以肯定我会来这个项目里复制一遍代码而不是重新敲一遍。

由于既涉及到前端组件又涉及到后端接口，以及一部分公共函数。我难道要把 Vue 的组件发布成一个 npm 包，把公共函数发布一个 npm 包，再把这部分后端接口重新起一个服务吗？

在一个全栈框架里这样做显然是有点繁琐。

假设 2：有一个付费网站，但它有一部分是免费的，付费内容也是分 vip、svip，如果全都写在一个项目里的话当然可以实现，毕竟用户也不关心你代码是怎么写的，只要能提供稳定的服务就可以了。

如果两个、三个网站呢？

如果是卖给客户源码呢？

如果是把免费内容开源，付费内容闭源，或是后续再把 vip 的逻辑开源呢？

假设 3：有一个基于 Nuxt 的开源博客站，如何设计一套机制，可以让其他用户用上自己喜欢的主题呢，毕竟博客最重要的就是换皮。

针对不同场景的解决方案

如果场景 1，前期 Layer 可以直接在 Nuxt4 应用里使用，像是这样：

app
	auth
		pages
		conmponents
		composables
		utils
		server
		nuxt.config.ts
	components
	composables
	utils
	app.config.ts
nuxt.config.ts

在 Nuxt3 中，这个 auth 可以放在 ～/layers 中
Nuxt3.12.0 以后的版本都会自动注册Layers

在 app 目录下，可以新建一个 {layer_name} 目录，目录内的结构和 Nuxt3 是一致的。

nuxt.config.ts 中只需要 extend 即可。

extend: [ 'app/auth' ]

这样，我们把权限校验相关的组件、接口、utils 都挪到了一个 auth layer 下管理。如果业务没能继续发展，一个仓库非常好管理，同时按文件夹划分后，结构十分清晰。

这样可能感受还不是很强烈。

因为只是目录结构上的分层。这一层相关的依赖 nuxt/auth 还是安装在了主项目内，但 nuxt-auth 已经是在 app/auth/nuxt.config.ts 里了，要知道，如果你用了一些 nuxt modules 之后，nuxt.config.ts 很容易变成一大坨！因为他们都是在这一个文件内配置。

但 Layer 可以随时分离出去，因为它就是一个完整的 Nuxt 应用，所以迁移几乎没有额外成本。

当决定把这一部分代码迁移出去时

可以直接使用官方的 layer 模板再新建一个项目 zc-auth-layer，这个模板有一个好处，内置了 .playground ，顾名思义，是一个用来模拟你的主项目的 Nuxt 应用。

Layer 的实际内容（红框）都写在根目录的123下，playground （绿框）里用来做调试和开发。

起初我没有用这个模板，而是单纯的新建一个 Nuxt 应用，但很快就发现了问题。Pages 会直接把主项目的 Pages 直接给覆盖掉，而且（暂时）还没发现如何忽略某个目录的覆盖，但这是一个显而易见的问题，应该会很快完善或者被我发现。

而有了 playground 之后，可以放心的里面写页面或是发展成一个独立的项目，又不影响外层供给其他项目继承。

这就是一个普普通通的 Nuxt4 应用！

而其他项目如果想使用它的仓库，只需要配置：

extends: [ ['github:aatrooox/zc-auth-layer', { install: true }] ]

也可以它发布后的 npm 包

// 直接使用npm 包
extends: [ 'zc-auth-layer' ]
// 某个组织下的包
extends: [ '@zzaoclub/zc-auth-layer']

就像是在项目中使用其他 components 、server api 一样！

甚至还拥有完整的自动导入和 TS 类型提示，这你能受得了吗？

依赖关系是这样的，A extend B ， B extend C ，C 拥有最高的优先级，向下覆盖。

所以哪怕是 B Layer 中只包含了一部分你需要的接口、组件，你也可以很轻松的再 extend 一个 D Layer，用来重写你不需要的逻辑。

比如 B C 都是支付层，B 是支付宝支付，C 是微信支付。

在主项目中使用 /api/order/pay 接口。继承了 B 层时，调用此接口就是支付宝支付，继承 C 后就是微信支付。

亦或是 B 的接口是 /api/order/pay/zfb ，C 的接口是 /api/order/pay/wx，主项目中的接口就可以用来自由控制使用哪种支付方式时调起对应的接口。

对于自己的项目来说，这种分层方式，可以让你更加自由的控制代码开源程度以及自己多项目复用逻辑。

对于出售源码时，也只需要出售对应层的代码，组合起来即可。

对解决博客换主题的功能，更是不能再适合了，只要按开发的博客时使用的 Components，组件名一一对应就可以了。

当然，如果实际应用到项目上，还有类似数据库、多环境等问题需要仔细斟酌。

但 Layer 的分层结构已经显而易见的更简单、更直接，开发体验也更好了。

潜在的问题

对于简单的前端项目，或是不涉及复杂的数据库架构，Layer 的方式无疑是更优雅的。

既在文件结构上解耦了，同时继承（覆盖）时也很直接。

但如果涉及到多个接口服务，或是多个数据库服务，甚至前端业务也比较复杂。还要是仔细测试其兼容性。

毕竟虽然使用 Layer 在文件结构上分开的，但实际打包后是在同一个 Nuxt 服务里的，并不是类似微服务的那种形式。

话说回来，大部分使用者应该只是看中了 SSR 能力，可能不会使用 Nitro 构建大型的应用，尤其是对于公司来说，也不太信任 Node 的服务能力。

所以对于个人开发者来说，我觉得 Layer 是个锦上添花的利器。因为大部分业务不会太复杂，而且偏前端更多一些。自己封装好的各种功能的 Layer 信手拈来，开发效率大大提高，还不耽误二次开发。

于是我在给自己的博客尝试增加了一个权限层 auth layer 后，才写下了这篇文章。

期待后续 Layer 的大放异彩。

2025 年的第 1 次复盘

Thu, 16 Jan 2025 00:00:00 GMT

从 2024/10/29 开始使用 Nuxt 的生态，掐指一算，已经有两个半月。

开始做时没有细致的规划多长时间内开发多少内容，只有一个大概的方向：先是从博客入手，然后设计一个类似朋友圈动态功能，然后设计评论系统，最后再写一个点赞功能。

陆陆续续提交了 300 多次代码。

就这样一直开发到感觉完善了 80% ～ 90% 左右的内容时，于是 1 月 10 号开始拆分功能。

一

在五天内拆出来两个仓库。

一个是博客站，增强了文章的属性，默认的 md 文件都被解析为单篇的文章。而一个特殊配置的目录下可以解析成文档，就像是 vitepress 生成的文档类似，我起了个名叫：小册。

开发下来，最大的阻碍就是 Nuxt 的生态教程太少，版本太落后。找资料比较费时间，有一些比较新的教程或知识点，都是在 youtube 上，在 github 里，还都是 Nuxt 生态的核心参与者自己出的教程或分享。

所以我多发一些 Nuxt 的内容应该是有一些意义的，然而这个意义取决于有多少人对 Nuxt 感兴趣，至于以后能开什么花结什么果，只能过一段时间再回过头来看了。

虽然可用教程少，但好处是外网发的内容准确度是很高。坏处还是我对它有所企图，生怕这个生态突然就嗝屁了，我的努力也付诸东流。

毕竟大环境是面向 BOSS 编程，BOSS 招人要什么技术，我就用什么技术。我多少有点背道而驰了，以至于时不时焦虑一下，但好在定力还可以，热爱还是能盖过一切。

另一个是 Nuxt 版的 Flomo，我这么说应该比较好理解，毕竟 Flomo 用的人多一些，我也起了个名叫 Memoz

功能主要参考 Flomo 和 Memos，但也不能全抄，有些我自己用不到的或是太费时的，都不能下功夫开发，因为在没有用户的情况下，我更倾向于输出一些干货文章以及录一些视频，有了围观群众之后再细细优化。

目前完成了 30% 左右，完成了基本的 md 内容渲染，标签功能，热力图已经有了想法，还没实现。但已经把两个项目的源码放在了 github 上，接下来也会多多公开编码。

对于使用者（我）来说，最核心的问题还是在碎片化的记录之后如何搜索和归纳整理，为生成新内容所用。所以完成一个基础版本后，我就会先用起来，在实际的使用中看看有什么问题。

二

考虑到最可能的结果是大肆宣传也没什么人关注，所以我需要尽快部署到更多的推广平台，混个眼熟。

v2ex 也发了个帖子，1770+点击，给博客站带来了170+新用户的访问，挺不错的。虽然留不住几个人，但是我需要多多感受贴近流量的感觉。

掘金 和 CSDN 还是得继续发，虽然阅读量感人，但是也算是在中文互联网上的一个 SEO 途径。

对比掘金、CSDN。公众号的大部分读者也不看技术相关的文章，还有的看了也就看了，没什么反馈。反正平台是不会给一个纯技术文大力推广的，除非在标题和封面上下功夫。

纯写技术不可取，还是要结合自己正在做的事，把故事穿插进来，读者更愿意围观正在做的事儿吧。

在过完元旦后，有强烈的想要录视频的冲动来着，选了一下录屏软件，但是转眼就过去半个月了，还没开个头，争取近日就录一下！

坚持长期做一些自己认为有意义的事确实没错，但现在我觉得要加一些条件了。

有些长期做能产生的价值，短期高质量的做也能产生相同的价值。

所以一旦正在行动中，想法就会随着行动的推进发生变动。如果没有行动，就只能空谈自己认为的价值。

说白了还是有点懒。

但对比过去一年的话，这两个月也能称得上“稳中向好”了。

三

1 - 2 个月复盘要比年度复盘要有用一些，可以迅速的调整状态。年度总结更多的表达对过去一年的遗憾以及对下一年的憧憬了。

我也不知道我为什么要复盘，以前也没复盘过，就是突然停了下来，回想了一下最近做的事，然后库库一顿码字，有点神奇。

接下来的要做的事，年前这几天应该是以整理文章、视频为主，每天有时间就开发一些新东西，毕竟快过年了，内心真的有点躁动了。

年后先把 Memoz 猛推进一波，然后同时写点东西，录点视频。

然后就开始开第三个坑： IMGX，一个极简、高效的内容美化工具，类似于生成卡片的 App 吧。

在二月份如果顺利的话，后两个产品应该都能初步完成。不顺利的话，那估计就是连第二个都完成不了。

反正不管开发什么产品，都有一些降级的收益：模板+文章+视频+教程。

我隐隐感觉，要在 25 年第一季度（4～5月份）进行更高强度的输出来获取到一些正反馈，今年才有可能发生转机，不然最有希望的又是下一年了。

最后，每天给自己留一些娱乐时间。

集中精力做事，把焦虑和犹豫的时间挤掉，就多出时间来放松自己了。

虽然目标远大，任务艰巨，但松弛感必须拉满，游戏都不玩，那真没意思了。

复盘结束 👏👏👏

Nuxt3.15.2升级报告

Thu, 16 Jan 2025 00:00:00 GMT

Nuxt3.15.1 升级到 3.15.2 ，同时 nuxt/content@3.0.0-alpha.8 升级到了 3.0.0-alpha.9

升级方式

npx nuxi@latest upgrade --force

运行后 nuxt/content 会同步升级，慎重！

破坏性

queryCollectionNavigation 的查询结果发生了改变

比如，我的这个collection定义如下：

book: defineCollection({
    type: 'page',
    source: {
      include: 'book/**/*.md',
      exclude: ['book/**/-*.md'],
      repository: 'https://github.com/aatrooox/Blog',
      authToken: process.env.CONTENT_REPO_TOKEN
    },
    schema: z.object({
      date: z.date(),
      lastmod: z.date(),
      tags: z.array(z.string()),
      versions: z.array(z.string()),
    })
  }),

// book/nuxt-book1/install/demo.md

alpha.8 时， queryCollectionNavigation 是不会包含最外层的目录的。数组直接以 nuxt-book1 开始，现在会最顶层的 book 也带上，导致我的博客小册相关的查询都要重构一下，这更新多少有点抽象了，不懂为什么改成这样的逻辑。

const { data: books } = await useAsyncData('navigation', () => {
  return queryCollectionNavigation('book', ['date', 'path', 'id'])
})

以前 books.value 就是 book 目录下的文件树，现在 books 是包含了根节点的整棵树

所以如何涉及到使用此导航树渲染的菜单都要改

另外，由于查询默认带上了根节点，所以导致每个文件的 path 也附带了完整的路径，从这个角度上看，这样改是合理的。

如果以前跳转时，自己拼接了前缀，也要去掉

同时因为 path 是完整的路径了，所以查询单个 book 时, 直接用 .path 就行了

const { data: page, error, refresh } = await useAsyncData(hash(route.path + 'page'), () => {
  // 删掉前缀
  return queryCollection('book').path(route.path).first()
}, { watch: [route.query]})

上个版本应该是不行的，不然我应该不会用 id 查

总之，查询单个md内容，直接用 queryCollection().path() 就行

而涉及到 queryCollectionNavigation 的部分，总结就是不管怎么筛选和查询，他会始终附带根节点

Nuxt Content v3 实现 RSS 订阅功能

Wed, 15 Jan 2025 00:00:00 GMT

这可能是对现在而言唯一一篇关于Content v3 版本的 RSS 订阅的文章了。我找遍了能搜出来的每篇文章，没有一个能用的。

因为 Nuxt Content v3 还没发布正式版，其相关生态的 module 都没支持最新的 Content , 感觉不是很复杂的功能，但是就不跟 content v3 一起出个 alpha 版，很无语。

本文来带大家在 Nuxt Content v3 里实现 RSS 订阅功能。

添加原始内容

在 content.config.ts 中 rawbody 是一个特殊的 schema ，配置后，将会把md原始内容存起来，在使用 queryCollection 时，就可以查到 rawbody 了

content: defineCollection({
    type: 'page',
    source: {
      include: '**/*.md',
      exclude: ['**/-*.md', 'book/**/*.md'],
      prefix: '/post',
      repository: 'https://github.com/aatrooox/xxxx',
      authToken: process.env.CONTENT_REPO_TOKEN
    },
    schema: z.object({
      date: z.date(),
      lastmod: z.date(),
      tags: z.array(z.string()),
      versions: z.array(z.string()),
      rawbody: z.string()
    })
  }),

在 server 中查询时：

// @ts-ignore
  const posts = await queryCollection(event, 'content').order('date', "DESC").all();

queryCollection 是可以在直接在 server 中使用的，不需要像 content v2中一样导入一个 serverQueryContent 。

而且 #content/server 这个导入方式在 v3 也不能用了

使用时，会产生错误的类型提示，目前只能忽略它（不影响使用）。可以查看 issue#2968

添加 feed.xml

找一个博客，点击他的订阅按钮，可以看到就是跳到一个 xml 页面上。

所以我们也只需要实现一个 feed.xml 即可，当然，一个网站也可以有多个 rss 订阅源

新建 server/routes/feed.xml.ts ，因为是基于文件路径的路由，所以此路由就对应 $baseUrl/feed.xml

在RSS阅读器上，也是通过输入这个地址来实现订阅。

添加相关依赖

rss
unified
remark-parse
remark-gfm
remark-breaks
remark-frontmatter
remark-directive
remark-directive-rehype
remark-rehype
rehype-sanitize
rehype-autolink-headings
rehype-stringify
hast-util-to-html

npm i rss unified remark-parse remark-gfm remark-breaks remark-frontmatter remark-directive remark-directive-rehype remark-rehype rehype-sanitize rehype-autolink-headings rehype-stringify hast-util-to-html

这些插件是围绕 markdown 和 html 的解析/转换相关的插件。

如果你想了解他们之间是如何运作的，可以去看 DIYgod 的这篇文章。以及这些插件在 xLog 中的具体用法。

我再挨个罗列出来介绍一遍，画个图，感觉没什么必要了，都是非常稳定且已经是事实上的标准的插件。

实际上 nuxt/mdc 就是使用了一系列 mdast、hast、remark、rehype 的插件，但是可惜的是它没有开放出对应的接口。

不然就不需要下载这么多插件了。

实现逻辑

直接放代码（忽略引入了，太长）：

/server/routes/feed.xml.ts

export default defineEventHandler(async (event) => {

  const config = useRuntimeConfig()
  // @ts-ignore
  const posts: any = await queryCollection(event, 'content').order('date', "DESC").all();
  const feed = new RSS({
    title: '早早集市',
    site_url: config.baseURL,
    feed_url: config.baseURL + '/feed.xml',
  })

  for ( const post of posts) {
    const content = post.rawbody
    if (content) {
      const markdownContent = cleanInvalidChars(content);
      feed.item({
        title: post.title,
        url: `${config.baseURL}/${post.path}`,
        date: post.date,
        description: post.description,
        custom_elements: [
          {
            'content:encoded': renderPageContent(markdownContent)
          }
        ]
      })
    }
  }

  const feedString = feed.xml();

  setResponseHeader(event, 'Content-Type', 'text/xml')

  return feedString

})

先来说明一下每一段主要逻辑

const config = useRuntimeConfig() 需要你在 nuxt.config.ts 中配置如下信息：

runtimeConfig: {
	baseURL: 'your url' // 或者使用环境变量覆盖
}

使用 queryCollection 获取到所有原始的 md 内容

我们的目的就是把每一篇文章都生成一个 feed item，所以循环所有文章，调用 feed.item()

此时出现了第一个问题： md原内容并不是等同于直接读取md文件，存在数据库中的原内容已经使变为了 \

所以为了使md能被正常解析，需要先清除一下没用的字符

同文件下：

function cleanInvalidChars(content:string) {
  return content.replace(/[\x00-\x08\x0B\x0C\x0E-\x1F]/g, '').replace(/\
/g, '
').trim();
}

处理好后，如果不写 custom_elements ，这个 feed 也已经有效了，但缺点就是无法在 RSS 阅读器中直接阅读文章内容。

所以刚才一堆插件，就是为了解析 custom_elements 里要塞入的 html 字符串

同文件下：

function renderPageContent(content: string) {
  const pipeline = unified()
  .use(remarkParse)
  .use(remarkBreaks)
  .use(remarkFrontmatter, ["yaml"])
  .use(remarkGfm, {  singleTilde: false })
  .use(remarkDirective)
  .use(remarkDirectiveRehype)
  .use(remarkRehype)
  .use(rehypeSanitize)
  .use(rehypeAutolinkHeadings)
  .use(rehypeStringify)

  const mdastTree = pipeline.parse(content)
  const hastTree = pipeline.runSync(mdastTree, content)
  return toHtml(hastTree)
}

此时，你可以在你的 RSS 阅读器中订阅自己的博客，然后看看是否能展示正常的文章内容了，或者在发布之前，先在浏览器打开 feed.xml ，观察 xml 内的文章内容渲染是否正确。

使用插件算是比较简单的实现方式了，搭配 AI 来手动写函数处理的话也是浪费了我不少时间，最后还有很多兼容问题，头铁的朋友可以试试

最后

欢迎订阅我的博客：RSS ，为你带来最新的 Nuxt 实战内容

链接: https://blog.zzao.club/feed.xml

插件库会随着时间逐步完善，所以本文同样具有时效性。但无论如何，文章开头的版本号代表本文的生效范围。

欢迎在评论区留下你的疑问和高见~

打造 Markdown 的绝美排版：@nuxtjs-mdc 使用指南

Mon, 13 Jan 2025 00:00:00 GMT

这是一份持续更新的@nuxtjs/mdc的使用说明书，扩充官方文档的同时，更正一些错误信息（因为官方更的不及时）。同时也会涵盖解析 Makdown 语法的使用说明。

安装

npx nuxi@latest module add mdc

然后 @nuxtjs/mdc 就会被自动添加到 nuxt.config.ts 的 modules 中

export default defineNuxtConfig({
  modules: ['@nuxtjs/mdc']
})

组件

MDC 中提供了三个组件来渲染 markdown 内容

MDC

<script setup lang="ts">
const md = "
	# h1 标题

	`代码快`

"

</script>

<template>
  <MDC :value="md" tag="article" />
</template>

MDC 组件直接接受一个 value prop，传入 markdown 的原始内容即可，tag 属性可以决定渲染后的内容被什么标签包裹，类似于 vue-router 的 RouterLink。

MDCRenderer

这个组件依赖于 parseMarkdown 函数提供的数据

此函数需要从 @nuxtjs/mdc/runtime 导入

import { parseMarkdown } from '@nuxtjs/mdc/runtime'

使用时可以像这样

<script setup lang="ts">
import { parseMarkdown } from '@nuxtjs/mdc/runtime'

const { data: ast } = await useAsyncData('markdown', () => parseMarkdown('::alert
Missing markdown input
::'))
</script>

<template>
  <MDCRenderer :body="ast.body" :data="ast.data" />
</template>

它还有第二个参数 MDCParseOptions，可以用来控制解析起的行为。

也可以在 nuxt.config.ts 中配置

import { defineNuxtConfig } from 'nuxt/config'

export default defineNuxtConfig({
  modules: ['@nuxtjs/mdc'],
  mdc: {
    remarkPlugins: {
      plugins: {
        // Register/Configure remark plugin to extend the parser
      }
    },
    rehypePlugins: {
      options: {
        // Configure rehype options to extend the parser
      },
      plugins: {
        // Register/Configure rehype plugin to extend the parser
      }
    },
    headings: {
      anchorLinks: {
        // Enable/Disable heading anchor links. { h1: true, h2: false }
      }
    },
    highlight: false, // Control syntax highlighting
    components: {
      prose: false, // Add predefined map to render Prose Components instead of HTML tags, like p, ul, code
      map: {
        // This map will be used in `<MDCRenderer>` to control rendered components
      }
    }
  }
})

点进去可以看到，这地址都 404 了，文件都删了，这就是为什么我要写这篇文章....

事实上，mdc 底层用到的很多插件，都是和 unified 的生态是一致的（都是基于remarkPlugins、rehypePlugins）。

但是 mdc 搞的有点太封闭。没导出几个有用的Api，其实完全可以把关于 markdown、html、以及中间的 hastTree 都开放出来。

因为 markdown 相关的内容，虽然没有官方的标准，但是因为使用范围很广，早就成了事实意义上的标准。有用的人自然会用了，不用的压根都不会看一眼。

实际使用中，这种方式还没有找到使用场景（在内容渲染中），不管是自己本地的数据，还是从第三方 API获取到数据，直接扔给 MDC 组件是最方便的，在数据中存储原始数据（rawbody），在不同平台展示时自身处理渲染逻辑。

PS：但要做 RSS 订阅就不得不把生成后的 HTML 放在 xml 中，这就是我上边为啥吐槽它太封闭。

MDCSlot

这个组件是为了替代 Vue 中的 slot 组件，针对 MDC 做了特殊处理，使用这个组件时你可以删除其包裹元素p，（使用 slot 时会默认渲染一个 p 标签包裹文字内容）

demo.md

ddddsadadasdasd

ProseP.vue

<template>
  <p>
    <!-- MDCSlot will only render the actual text without the wrapping <p> -->
    <MDCSlot unwrap="p" />
  </p>
</template>

当你输入两段纯文本，并且中间有一段空行时，这两段文本会分别被 p 标签包裹，做到换行的效果。

而如果用上述的 ProseP.vue 覆盖后，纯文本将不再被 p 标签包裹，而是变成了 span，也就是你在写 md 时，哪怕已经换了行，渲染后的内容也是连贯的排列在一起的。

那 ProseComponent 是什么呢

Prose Component

MDC 渲染 markdown 内容时，使用了一套组件来渲染对应的 markdown 语法

同样的也支持你覆盖这些组件

如果你使用 nuxt3.15.1 并且开启了 compatibilityVersion: 4，那你的 components 路径应该是在 app/components

在此路径下新建目录 mdc ，然后创建一个同名的 vue 文件：ProseA.vue

我改写了其样式，并且把跳转默认为打开新标签页

可以看到如上渲染内容

自定义组件

MDC 还支持在 markdown 中写 vue 组件，语法是这样的

demo.md

::component-name
This is an vue component
::

对应 app/components/mdc/ComponentName.vue

如果你正在搭配 Nuxt Content 使用，则对应目录为 app/components/content/ComponentName.vue

再来个更实际的例子

md 内容为：

下面是一个 CustomTag 组件

::custom-tag
内部内容演示
::

组件位于`app/components/mdc/CustomTag.vue`

CustomTag.vue 内容为：

<template>
  <div class="text-center my-10">
    <div
      class="text-black px-3 py-2 text-lg font-bold">
      <slot/>
    </div>
  </div>
</template>

<script setup lang="ts">

</script>

渲染后的结果为：

这种组件被称为 Block Components ，和 display: block 的意思相同，是个块级组件，单独占一行

既然是Vue组件，也给它传 props

::custom-tag{type="warning"}
内部内容演示
::

再把组件改一下

<template>
  <div class="text-center my-10">
    <div
      class="text-black px-3 py-2 text-lg font-bold" :class="{ 'bg-yellow-200': props.type === 'warning', 'bg-blue-200': props.type === 'info', 'bg-green-200': props.type === 'success', 'bg-red-200': props.type === 'error' }">
      <slot/>
    </div>
  </div>
</template>

<script setup lang="ts">
const props = defineProps<{
  type?: 'warning’ | ‘info’ | ‘success’ | ‘error’'
}>()
</script>

`
看下渲染的内容：

也可以直接传 style

::custom-tag{type="warning" style="margin-top:100px;"} 
内部内容演示 
::

可以看到有了一个很大的间距

还支持使用 YAML method 的方式传入

::custom-tag{type="warning" style="margin-top:100px;"} 
---
desc: "我是描述内容"
---
::

把组件改为

<template>
  <div class="text-center my-10">
    <div
      class="text-black px-3 py-2 text-lg font-bold" :class="{ 'bg-yellow-200': props.type === 'warning', 'bg-blue-200': props.type === 'info', 'bg-green-200': props.type === 'success', 'bg-red-200': props.type === 'error' }">
      <div class="title">
        {{ props.type }}
      </div>

      <div class="desc text-red-600">
        {{ desc }}
      </div>
    </div>
  </div>
</template>

<script setup lang="ts">
const props = defineProps<{
  type?: 'warning' | 'info' | 'success' | 'error',
  desc?: string
}>()
</script>

渲染后：

不过这种方式，不能和 slot 混用，渲染出来 slot 会把几个 props 都覆盖。

实际使用时，不应该对一个内容写如此复杂的组件。

换句话说，Vue 组件应该足够完善，让你在 markdown 中写足够少的信息，只传入必要的数据即可得到完美的展示才对。

上面的 Props 是我们自定义的组件提前写好的 Props ，而内置的 Prose Components 也是一套 Vue 组件而已。

所以除了在 app/components/mdc/ 下创建一个同名的 Prose Component 覆盖原有组件，也可以直接给原组件传一些 style，改变它的样式。

Attributes work on:

- ![favicon](/favicon.ico){style="display: inline; margin: 0;"} image,
- [link](#attributes){style="background-color: pink;"}, `code`{style="color: cyan;"},
- _italic_{style="background-color: yellow; color:black;"} and **bold**{style="background-color: lightgreen;"} texts.

除了使用一个 Vue 组件并给他传 Props，设置 style

还能使用 :ComponentName 的语法直接使用一个写好的组件，比如这样

# Title

:banner

Banner.vue

<template>
  <aside>
    This component does not have any children.
  </aside>
</template>

这在自己定制的平台上使用时，会很有用。但同样的，如果你使用其他软件或 API 来获取 md，要考虑一下语法过多导致的各平台不兼容问题。

PS: 这种md里写属性传值的方式并不是 mdc 的原创，而是 unified （remark/rehype）插件相关的生态，都是这样写的。

绑定数据

贴两个官方的例子，很好理解

第一种是在 Markdown 的 YAML 中定义：

---
title: 'Title of the page'
description: 'meta description of the page'
customVariable: 'Custom Value'
---

# The Title is {{ $doc.title }} and customVariable is {{ $doc.customVariable || 'defaultValue' }}

这个用法很有局限，因为你用来写 md 文章的软件大概率不支持这个语法，或者你要同步到其他平台的时候其他平台也不会支持这个语法。

但是如果你的用途很单一，说不定会比较有用

第二种是定义在 Vue 组件中

<template>
  <div>
    <ContentRenderer :value="data" :data="mdcVars"/>
    <button type="button" v-on:click="mdcVars.name = 'Hugo'">Change name</button>
  </div>
</template>

<script setup lang="ts">
const { data } = await useAsyncData(() => queryCollection('content').path('/test').first());
const mdcVars = ref({ name: 'Maxime'});
</script>

md 中

# Hello {{ $doc.name || 'World' }}

还是那种话，定制的越多，越不可控。

文章内容还是要以高质量的文字为准，自定义组件更多的是作为锦上添花，是离不开一个封闭的平台的。

官方还给出了一种自定义组件的方式，就是在 nuxt.config.ts 中配置 prose: false，关闭 Prose Components 的渲染方式，自定义一个 map 指定组件

mdc: {
    // components: {
    //   prose: false,
      // map: {
      //   'a': 'MemoProseA'
      // }
    // }
  },

但我觉得这种方式和直接在 mdc 目录在覆盖掉原组件的区别很小，这种方式可以做到只支持部分 md 语法的渲染，比如你只写一个 a ，那其他内容就是纯文本，只有 a 标签是通过自定义组件渲染出来的，不清楚什么场景下才会有这种选择～

tailwind CSS 主题

Prose Components 支持使用 tailwindcss-typography 覆盖 html 排版

这是我觉得比较实用的样式修改方式，因为 tailwindcss 足够通用，并且在全局的固定位置修改样式，便于管理

Tailwind CSS Typography 提供了一组 prose class，可以给默认的 html 元素附加排版，➡️点击查看演示

<article class="prose lg:prose-xl">{{ markdown }}</article>

安装插件

npm install -D @tailwindcss/typography

新建或添加到 tailwind.config.js 中

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    // ...
  },
  plugins: [
    require('@tailwindcss/typography'),
    // ...
  ],
}

修改灰度

prose prose-gray(默认) prose-slate prose-zinc prose-neutral prose-stone

不管使用哪个，都要带有 prose 这个基类

文字整体尺寸

prose prose-sm (14px) prose-base (默认16px) prose-lg (18px) prose-xl (20px) prose-2xl (24px)

和灰度一样，也要带有 prose 这个基类，实际使用下来，还是 prose-base 用的最多，可以在自己发文发帖的多个平台尝试不同字号

适配深色模式

上面的几个调整灰度的主题，都有默认的深色模式版本，可以使用 prose-invert 来触发

<article class="prose dark:prose-invert">{{ markdown }}</article>

如果你使用了自定义组件，则需要自己使用 dark: 修饰符适配一下深色模式

Nuxt 中使用 @nuxtjs/color-mode 来控制颜色模式

精细化控制样式

除了全局设置默认的样式，也可以通过 prose-xxx 来控制目标标签的样式

像这样：

<article class="prose prose-a:text-blue-600 hover:prose-a:text-blue-500">{{ markdown }}</article>

另外，每个修饰符都为了保证内容的可读性，设置了最大宽度。如果你希望内容能够填充其容器的宽度，可以使用 max-w-none

<article class="prose max-w-none">{{ markdown }}</article>

取消 prose 样式

使用 not-prose 标记一些元素，不使用 prose 的样式

<article class="prose">
  <h1>My Heading</h1>
  <p>...</p>

  <div class="not-prose">
    <!-- Some example or demo that needs to be prose-free -->
  </div>

  <p>...</p>
  <!-- ... -->
</article>

但无法继续在 not-prose 里再嵌套 prose

自定义颜色主题

可以在 tailwindcss.config.js 中设置自定义的颜色主题

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    extend: {
      typography: ({ theme }) => ({
        pink: {
          css: {
            '--tw-prose-body': theme('colors.pink[800]'),
            '--tw-prose-headings': theme('colors.pink[900]'),
            '--tw-prose-lead': theme('colors.pink[700]'),
            '--tw-prose-links': theme('colors.pink[900]'),
            '--tw-prose-bold': theme('colors.pink[900]'),
            '--tw-prose-counters': theme('colors.pink[600]'),
            '--tw-prose-bullets': theme('colors.pink[400]'),
            '--tw-prose-hr': theme('colors.pink[300]'),
            '--tw-prose-quotes': theme('colors.pink[900]'),
            '--tw-prose-quote-borders': theme('colors.pink[300]'),
            '--tw-prose-captions': theme('colors.pink[700]'),
            '--tw-prose-code': theme('colors.pink[900]'),
            '--tw-prose-pre-code': theme('colors.pink[100]'),
            '--tw-prose-pre-bg': theme('colors.pink[900]'),
            '--tw-prose-th-borders': theme('colors.pink[300]'),
            '--tw-prose-td-borders': theme('colors.pink[200]'),
            '--tw-prose-invert-body': theme('colors.pink[200]'),
            '--tw-prose-invert-headings': theme('colors.white'),
            '--tw-prose-invert-lead': theme('colors.pink[300]'),
            '--tw-prose-invert-links': theme('colors.white'),
            '--tw-prose-invert-bold': theme('colors.white'),
            '--tw-prose-invert-counters': theme('colors.pink[400]'),
            '--tw-prose-invert-bullets': theme('colors.pink[600]'),
            '--tw-prose-invert-hr': theme('colors.pink[700]'),
            '--tw-prose-invert-quotes': theme('colors.pink[100]'),
            '--tw-prose-invert-quote-borders': theme('colors.pink[700]'),
            '--tw-prose-invert-captions': theme('colors.pink[400]'),
            '--tw-prose-invert-code': theme('colors.white'),
            '--tw-prose-invert-pre-code': theme('colors.pink[300]'),
            '--tw-prose-invert-pre-bg': 'rgb(0 0 0 / 50%)',
            '--tw-prose-invert-th-borders': theme('colors.pink[600]'),
            '--tw-prose-invert-td-borders': theme('colors.pink[700]'),
          },
        },
      }),
    },
  },
  plugins: [
    require('@tailwindcss/typography'),
    // ...
  ],
}

也可以使用自定义的色值

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    extend: {
      typography: {
        DEFAULT: {
          css: {
            color: '#333',
            a: {
              color: '#3182ce',
              '&:hover': {
                color: '#2c5282',
              },
            },
          },
        },
      },
    },
  },
  plugins: [
    require('@tailwindcss/typography'),
    // ...
  ],
}

不过不建议在这里配置颜色相关的，因为提供了通过 prose-xxx 的形式灵活控制样式时，在这里在写一遍自定义的样式会难以覆盖，可以在这里设置一些间距类的样式。

而颜色使用一个自定义的 class 去使用：

.mdc-page-prose {
  @apply prose prose-zinc prose-pre:bg-gray-100 dark:prose-pre:bg-zinc-400 dark:text-zinc-200 dark:prose-strong:text-zinc-200 prose-code:bg-zinc-200 dark:prose-code:bg-zinc-200 prose-code:text-zinc-800 dark:prose-blockquote:text-zinc-300 w-full max-w-full
}

.mdc-prose {
  @apply prose prose-zinc prose-pre:bg-gray-100 dark:prose-pre:bg-zinc-400 dark:text-zinc-200 dark:prose-strong:text-zinc-200 prose-code:bg-zinc-200 dark:prose-code:bg-zinc-200 prose-code:text-zinc-800 dark:prose-blockquote:text-zinc-300 w-full max-w-full
}

这样的话，在一个项目中，出现两组或多组不同的 prose 样式，就比较方便使用 class 控制了，毕竟 tailwindcss.config.js 只有一个，尽量设置一些通用的不常变化的属性。

结语

以上就是 nuxtjs/mdc 的大部分使用场景了，通常这个库会在使用 Nuxt Content 时使用，但也可以只使用它来支持多种来源，片段化的 md 内容渲染。

但是要注意，虽然支持自定义组件，但我还是不建议你的 md 文章里不要包含太多的魔法，在自己定制的平台上是魔法，在其他不支持的软件和 web 里就是麻瓜。

但是自定义组件很适合用来支持自己的自建平台，这也是我为什么会把 mdc 这个库拿出来单独使用。

使用时注意文章开头的 mdc 版本号，表示此文章的生效范围，后续更新只能在我的博客站同步了

如果你也是 Nuxt 的使用者，或是 Vue 使用者对 Nuxt 感兴趣，欢迎在文末或博客站首页添加我的微信，一起交流，知无不言😎

博客站还有很多功能可以完善，但不得不进入优化期

Mon, 13 Jan 2025 00:00:00 GMT

目前博客站对于 Obsidian 的文章有了一个基本的渲染功能。

可以拉取指定Github仓库的文章，生成站点，也能配置某个目录下的文章为小册的展示方式。

我知道还有很多功能不足，比如 sitemap、静态化、robots.txt、rss 等。

但 @nuxtjs/seo 这个 module 还未支持最新版的 Nuxt Content

所以博客的内容只能先做减法，优化一些 UI 方面的细节

export default defineNuxtConfig({
  modules: ['@nuxtjs/mdc']
})

同时，因为我是先做了一个大的项目，然后又从中抽离出博客这个站点。

所以，本项目上也存在不少冗余代码，最近有时间我就会清理一下。

还有包括具体的使用教程，也会优先完善（如果有人用的话）。

同时，也从 Gitea 设置了 Github 的镜像仓库，如果侥幸有人使用的话，能够反馈一些不足之处是最好的。

Github

2025年01月14日11:34:17 更新

就在13号在 sitemap 的 github 提了 issue 之后， 14号就发布了 v7.0.2 版本

不过倒不是支持了 nuxt/content 而是检测如果使用了v3版本的content，则不会去自动引入content了

所以，可以自己手动去生成 sitemap 了

靠坚持做不成长期主义

Mon, 06 Jan 2025 00:00:00 GMT

做成一件长期的事前，有不止九九八十一难。

对于一个不是天生就专注且后天也没刻意学习过时间管理的人来说，每天发生的小事和决策都会影响一个计划的进行。

打满鸡血时，极其上头，通宵达旦，不知疲倦。

然后突然就因为一些不经意的小事，感觉失去了所有的意义。

我觉得根本原因有几个，其一是要做成这件事本身就很苦，其二是没有那么强的自驱力。

就拿上班举例。

因为都是苦逼的普通人，所追求的不过是让自己或家庭过得更好一些。

为了维持生活，就要维持稳定的收入，所以才需要一份稳定的班上。

但上班是什么性质，这个就不必多说了吧😅

上班就是纯纯的坚持

其他的收入方式，要么不适合，要么不稳定，所以哪怕上班再不喜欢，刀架脖子了就得去坚持，这是实实在在的压力。

其次，上班了会发工资，而且还是每个月或定期发。

你品一品，这个模式像极了为了保住日活月活的游戏运营商...

一个游戏，要想吸引大量的人涌入，先是讲讲故事，讲讲特色，吸引你的注意。

入场后，为了维持住玩家，先是扩充玩法和剧情，增加新鲜感，吸引更多的玩家。

等你已经电子羊尾了，再时不时搞点登录就送、签到满x天就送x的活动，就吊着你，维持虚假繁荣。

因为黑红也是红，那虚假繁荣怎么就不是繁荣了呢。

这算一种激励！

回过头来想，对于要做一件自己自由规划的长期的事来说，一般是没有人拿刀逼着你去做的。

而如果存在很大的外在压力，通常也不会选择去做长期的事，这种情况往往需要在短期获得收益。

至于有压力但不够，可以归结为没有压力，因为对应到事儿上都属于做不成事儿。

但是谁不想把事儿做成呢。

我这种，想做出点事又没有强大自驱力的人怎么办呢。

在我边打鱼边晒网的做事过程中，我发现其实并不需要全身心投入和100%自驱，有时候能有60%就有不错的效果，因为我要做的事也不是什么大事。

我能给自己一些压力，但是不够我抵达目标。

就好像一个上升的台阶，10米，就俩台阶，那我上不去。如果是5个台阶，我如果身体强壮的话，能试试。如果是10个台阶，那就很有信心登上去。

那如果是九九八十一个台阶呢？

问题似乎就是如何在苦哈哈的做一件事时，时不时来个甜枣或巴掌。

思考到这里，我意识到如何给甜枣或巴掌都是一件需要长期平衡的事。

放在做独立开发一个产品上，是为了差异化，为了增加用户粘性，让产品更有人情味。

放在家庭教育上，谁来给？给多少？甜枣多了怕齁着，巴掌大了也怕打蒙了。

一开始我想：这种事往深了想没有意义，因为不要求做到100分，考虑太细致反而受其乱。

但是我此刻笃定极有意义。

不过意义不是如何做到100分，而是如何把60分完成的游刃有余。

毕竟对于一个差一步都“登顶”不了的普通人来说

你怎么知道此刻的思考不是你的下一步台阶呢？

碎碎念 END ....

2025 年，我打算 All in Nuxt

Thu, 02 Jan 2025 00:00:00 GMT

最近用 Nuxt 搭建了一个博客站，把 Obsidian 的文章无痛搬过去，可算是收了个小尾。

展示一下成果😎

首页，展示个人信息、最近文章

当然，也必须支持暗色

文章页，主要是支持分类查询和分页

小册，顾名思义：把文章整理成册就是小册，适合系统的整理某些资料

小册内根据 Obsidian 的目录结构来展示

也做了移动端适配

当然，审美这块儿，见仁见智....

然后再说一下，目前关于写文章的相关工作流。

目前使用 Chrome 的 lighthouse 测试，性能 98 ，SEO 100

数据统计使用 Google Analytics，手动插入 scripts 即可。

首先 Obsidian 的文章通过 Github 进行多端同步，插件是 Obsidian Git，设置定时 commit 定时 pull 定时 push。

使用 Obsidian 插件 Linter 进行格式化 YAML 信息，自动添加标题、描述、创建时间、修改时间等。

使用 Obsidian 插件 image auto upload plugin 上传插入的图片到腾讯云 COS，上传后删除源文件，一般我的图片都是从本地复制过来的，留在仓库里也没什么用。

腾讯云对象存储设置私有读写，套 CDN 和设置个人域名+SSL证书进行访问，CDN 设置流量上限，开启防盗链等，避免被人刷太多。

写完就不用管了，自动上传到 Github，但是还没自动触发部署操作，这个后续再加吧～

有“家”了之后，新的一年就好好整理一下屋里的东西（文章）吧

最后

最近的所有开发都围绕 Nuxt 展开，2025 年也打算深入投入到上面。但学习和开发过程中，发现可搜到的文章、视频都非常少（主要是看核心开发人员自己发的 youtube 视频），可交流的小伙伴也不多。

所以，文章和视频部分，我准备自己发布一些。

交流场所的话，就建个交流群吧。

如果你也是 Vue / Nuxt 的使用者，想了解和使用 Nuxt ，欢迎加我好友👏。

博客地址在消息菜单里可以找到

App 下滑上二楼到底是谁发明的

Tue, 31 Dec 2024 00:00:00 GMT

不知道从什么开始，很多 App 在首页加了个下滑上二楼的功能。

且先不说这功能好不好用。

你说一个 App，肯定有个定位对吧。外卖的就是点外卖的，银行的就是转账的，打车的就是摇车的。

底下三个入口都满足不了你是吧？

第一个 Tab，点外卖，第二个 Tab 借钱，第三个 Tab 短视频，不是你真缺钱，你把贷款放在首页呗，怎么还藏着个点外卖的功能啊。

nuxt/content运行或编译时报错unhandledRejection

Fri, 27 Dec 2024 00:00:00 GMT

 ERROR  [unhandledRejection] TAR_BAD_ARCHIVE: Unrecognized archive format 09:45:32

此错误出现在使用了 nuxt/content 的 repository 配置。

原因是一般是 github 仓库拉取失败

检查是否是有效的 github 仓库地址
检查该仓库是否配置了 accessToken
检查 accessToken 的权限中是否包含可读仓库
自身网络是否有问题

排查时，npm install 有时也会报此错误，基本是因为网络问题，可以尝试挂一下代理。

震惊，我在同时打三份工！

Wed, 18 Dec 2024 00:00:00 GMT

最近在同步开发两个私活，一个基于Flutter的App，一个基于Vue2的可视化大屏。再加上主业，竟然同时在搞三份工，纯牛马了属实是。

App仅仅要求开发一个安卓App，没有要求开发使用的语言。

本来我第一预期框架肯定是uniapp的，但这个App工期比较松，于是想选个没用过的玩一下😏

因为只要求安卓，于是我花了两个小时把kotlin官方入门文档读了一遍，读完甚至觉得还挺简单，TS类型折腾起来比它麻烦（我胡说的）。

但是觉得kotlin还是有些局限性（多端上），而且依赖Java库，又去v2ex搜了下网友的建议，有些甚至建议先学Java。我对学Java很排斥，因为感觉遍地都是Java，我再怎么学也无法弥补相对于其他Javaer来说入行晚的巨大劣势，所以迅速抛弃了kotlin。

那最后为什么转投了flutter呢，很简单，打开招聘软件，搜索uniapp / flutter/ RN 等关键词，哪个岗位多，薪资高，就选哪个。

虽然我身在一个二线的省会城市，但是Flutter相比其他俩来说在岗位数量和薪资上优势还是很大的。

uniapp 不是不行，而是门槛太低，薪资太低，所有前端都能直接拿来使用，也是大部分小公司或传统企业要开发app、小程序的首选。但这玩意什么门槛都没有（我瞎说的），我没有要去做的动力。

而且在用户和开发者的角度，我不认同损失性能和体积，去低成本的实现一个勉强能用的App的这种做法，这基本就是对用户在做服从性测试（反正难用你也得用，没得选）。

但作为公司的角度，只有成本才是唯一的考量，我也非常理解。

幸好用Flutter开发完没让我失望，真的很丝滑，打包体积也只有19m 后续还能编译到其他平台。

说起来，学 Flutter 的过程也有点跳跃。

本来我打算先看一遍文档的，但是问了一嘴做过 FlutterApp 的朋友，他随手甩了我一个链接，是一个 Flutter 的佬（小呆呆）写的关于 Getx 的使用简介。

于是我顺着他的文章读了几篇，大概摸索清楚了在 Flutter 中如何使用 Getx 管理数据及交互逻辑层，虽然此时我还完全不清楚Flutter的语法，但也不妨碍我理解 Flutter 中的一些设计方式。

于是在简单建立了整体结构、几个页面、和基本的交互逻辑后，我用 Getx 小小的重构了一下，直接加深了不少理解。

中间我又注重看了几个关于 Flutter 中 Controller、 State、布局约束、ChangeNotifier的视频讲解，其中最推荐的是 B站：王叔不秃，讲的忒好了。

看的同时，每天下手去开发，然后就发现最不熟悉的反而成了UI组件🥲，因为我一开始就默认了开发UI界面没有难度，所以优先去看了状态管理怎么做....

由于UI比较简单，重构的也比较早，所以并没有看到所谓的“嵌套地狱”，整体开发体验（Android Studio）是很不错的。

中间磕磕碰碰的都是些 Android 原生配置需要去搜，这玩意是真一点也看不懂。不过幸好，只要配好了，开发时是不需要管的。

总之，在大概 3-4 人日的工作量下完成了这个Flutter App。

至于Vue2的大屏，Vue的生态用的实在是太多次，所以没有什么意外。

这次接下来就当是测了一下开发的极限速度，因为活很急，最终总共开发时间不到20小时。

PS：大屏实在是太适合做低代码了，但是似乎没见过什么源码进源码出的低代码平台，可能是每个公司都有自己的业务需求，做出来很难通用吧，所以我简单花了个架构图，准备后面自己搞一下。

现在到了收尾阶段，又可以写点东西，做自己的项目啦~~

其实做私活，最重要的是又多了个开发模板，方便下次更快的启动，同时也能沉淀出自己的东西，

做的越多，做的越快。

最怕纯消耗时间，什么都没积累下。

这可能就是同样是在做拿时间换钱的活，不同人之间的差别所在吧。

nuxt-content v3 使用及迁移记录

Fri, 06 Dec 2024 00:00:00 GMT

这是一篇关于 nuxt/content v3 版本的使用和迁移指南，分享一下我在使用 nuxt/content 时的一些经验和问题。

此前，我基于 v2 版本完成了博客内文章的渲染，在发布了 v3 版本后，我第一时间更新到了最新的版本。

在之前的文章《基于 Nuxt3 + Obsidian 搭建个人博客》中，我已经分享了全部配置以及用法。

大概思路是使用 Obsidian 在本地来管理的文件，在发布时在本地打包，将打包后的 .output 文件部署到服务器上。这样完全没有破坏以前的写文章路径，同时通过一个简单的插件给文章页面加上了一个复制到公众号的选项，做到了在公众号和个人博客站展示一致。

之前存在一个问题，解析非英文路径时，会把非英文的部分直接丢弃掉（或识别不出来），在 v2 中解决办法是在 server/plugins 中增加一个 hook ： content:file:beforeParse ，手动去处理文件的原始内容，插入一个 _path 属性，以此保留了原始的中文路径，算是一个十分膈应的解决方式。

但 v3 版本是破坏性升级，核心的部分也已经被重构了，~~所以 v2 使用的 hook 也不存在了。~~ 更正：文档突然冒出来的，真的！还有两个 hook content:file:beforeParse 、content:file:afterParse

虽然还有，但是 v3 版本已经不需要使用此方式解决！

我在 issues#2889 提出了这个问题后，很快也得到了 pull#2889 解决，所以你如果使用的是 v3.0.0-alpha.8 及以后的版本，想必都是可以的。

export default defineNuxtConfig({
  content: {
    build: {
      // 虽然官方没有写 markdown: {} ，实际 ts 提示这个配置是必须的
	  markdown: {},
      pathMeta: {
        slugifyOptions: {
          // Keep everything except invalid chars, this will preserve Chinese characters 
          remove: /[$*+~()'"!\-=#?:@]/g,
        }
      }
    }
  }
})

另外 v3.0.0-alpha.7 连内容搜索时的分页 api 都没支持好，所以最起码也要用 alpha.8 及以后的版本了。

配置层面，现在拓展性更强了一些，并且提升到了一个新的 content.config.ts 中

import { defineCollection, z } from '@nuxt/content'

export const collections = {
  content: defineCollection({
	// 表示文章和目录是一对一的关系，一个文件会生成一个路由
    type: 'page',
    source: {
      include: '**/*.md',
      exclude: ['**/-*.md'],
      // 设置读取content的根目录
      cwd: '/Users/aatrox/notion/blog',
    },
    schema: z.object({
      date: z.date(),
      tags: z.array(z.string()),
      versions: z.array(z.string()),
    })
  })
}

包含哪些文件，忽略哪些文件可以自由配置，新增的 front matter 属性，如 versions，也可以自行添加。

v2 版本时，content 是在运行时把文件存储在 cache 目录下。而 v3 版本彻底抛弃了 file 模式，直接转为了 sqlite 存储，所以相对应的，内容相关的查询和渲染 API 也都进行了修改

queryCollection 的替换

// 分页查询
queryCollection('content').skip(skip).limit(10).all()
// 查数量
count.value = await queryCollection('content').count()

useContent() 被移除了。

<ContentDoc>, <ContentList>, <ContentNavigation> and <ContentQuery> 这个三个组件也被移除

fetchContentNavigation() API 被替换成了新的 queryCollectionNavigation()

markdown 文本中的 ._path 被改为了 .path

一些和旧版 content 配套使用的 sitemap 逻辑也应该删除 /server/routes/sitemap.ts

当在 pages/xxx/[...slug].vue 渲染文章时：

const { data: page } = await useAsyncData(route.path, () => {
    return queryCollection('content').path(decodeURI(route.path)).first()
  })

需要使用 decodeURI 才能在数据库中匹配到对应的文章。因为路径中包含中文

更详细的迁移说明，可以移步官方迁移文档。（或者等我想起来，会更新在博客站中）

现在使用 v3 开发模式时，会在根目录下创建一个.data 目录，然后生成一个 sqlite 文件用于存储文章内容。

并且这个数据库不需要你来管理，只要配置好内容来源和规则。

修改为最新版的 api 后，我又增加了一项改动，把从本地文件获取文章改为了从 github 仓库获取。

原因是，以前我在公司和家里用的同一个笔记本，没有感知到什么问题。现在家里添置了一个新的 macmini ，我在家里配置好了同样的环境后，两边带着个 output 文件在 git 上太诡异了，而且本地的路径也不一致。

也就是需要修改一下 content.config.ts

source: {
      include: 'blog/**/*.md',
      exclude: ['blog/**/-*.md'],
      prefix: '/post',
      // cwd: process.env.CONTENT_FS_PATH,
      repository: 'https://github.com/aatrooox/xxxxx',
      authToken: process.env.CONTENT_REPO_TOKEN
    },

配置上自己的仓库地址，以及对应的 authToken.

authToken 的配置在 github => 点击我的头像 => settings => 左侧最下方 developer settings => Personal access tokens => fine-grained tokens

为某一个库生成 token，同时不要忘记给他放开 read-only 权限

最后生成是可以看到有哪些权限

如果你生成了 token，但是没给权限，最后使用 content 运行时报的错压根不会让你想到是 token 的权限问题。别问我怎么知道的。

如果本地文件比较多的，建议给本地的知识库划分一下仓库。一是 obsidian 自己如果文件太多，也会有性能问题，二是 nuxt/content 要去拉取你的代码，太多了拉的也慢。三是划分好后，哪些文件时对外展示的也比较清晰。

配置 content 的 repo 时，就配这个需要对外生成文章的仓库就好了。

当运行 dev 时，刚才提到的本地数据库目录 .data，下会多出一个 github-aatrooox-xxx-main，里面就是所有原始的文件。当应用执行第一个查询检索内容时，就会读取上一步已经生成的 Dump 恢复到目标数据库中，同时有一套检查机制确保数据库中为最新的内容和避免重复导入。在客户端导航时，会在浏览器中初始化本地 SQLite，初始化后所有查询就是在本地进行了，所以 v3 的查询要比 v2 感觉上快很多。

以上就是 v3 的使用指南，基于官方的迁移说明，并且还解决了一些中文互联网才会有问题。

另外现在最新版处于不稳定状态，建议观望一下再升级，并且 nuxt/content 在网络上热度不高，出现奇怪的问题都没地儿找答案。

如果你恰好也是 Nuxt 的使用者，欢迎关注我，一起来讨论。

👋👋

如何防止别人把域名解析到自己的服务器公网 ip 上

Wed, 04 Dec 2024 00:00:00 GMT

我遇到了一个很奇葩的问题，以前没遇到过：就是有个网站解析到了我服务器 ip 上。

我是怎么发现的呢，一开始我是在看 CDN 的监控指标，里面有个 referer 来源，本来应该都是我自己的域名，但是跑出来一个陌生的域名。

于是我打开了这个域名，好嘛，这不就是我的网站么🥲

这个域名还是个子域名，主域名上什么也没有，也看不到他的购买信息。本来想去问候一下。

我就开始寻找解决办法，求助 AI，求助身边的运维朋友，可惜朋友没回...

然后我就先把 cookie 的 samesite、domain、secure 设置好，确保接口不会被一直调用。但是我文章里的图片是个问题啊... 因为我把图片都存在了腾讯云上，他这个网站访问的时候，也会走我的流量，但是我当时又没找到办法解决，只好把主域名的 Nginx 配置先停掉了

过了几天后，我又想起这个事儿，然后又换了个 AI 问了一遍，还是让我设置 Nginx 就行

显示加了一个

add_header X-Frame-Options "SAMEORIGIN";

这个只是不允许其他网站嵌入

然后又设置的

server {
	listen 80 default_server;  # 这个 server 块是默认的
	server_name _;  # 匹配所有未定义的域名

	return 301 https://zzao.club$request_uri;  # 重定向到 HTTPS
}

即 80 端口上如果有我没配的域名，则重定向到我的域名

当时尝试了，没成功，应该是因为加了 https，导致规则没走这条。大意了！

这次把 https 换成 http，发现其实是生效的

于是照猫画虎，把 443 端口也堵上

server {
	listen 443 default_server;  # 这个 server 块是默认的
	server_name _;  # 匹配所有未定义的域名
	
	ssl_certificate /etc/nginx/aaa.pem;  # 指定证书的位置，绝对路径
	ssl_certificate_key /etc/nginx/bbb.key;  # 绝对路径，同上

	return 301 https://zzao.club$request_uri;  # 重定向到 HTTPS
}

再次访问那个域名，会自动跳到我的域名了！

虽然解决了，但是还是很奇怪

解析到我的网站有什么用呢，我的网站没有用户，没有价值....

还是说他只是批量的尝试，碰巧扫到我的了

不过有了这次的经历，Nginx 的配置倒又学到了一点😛

sss

新买了 Mac Mini !!

Tue, 03 Dec 2024 00:00:00 GMT

很久没有更新设备了，这次新买了最低配的 mac mini 16+256。教育优惠 3749 到手！

然后幸亏家里还有个一直没卖没扔的苹果鼠标，以为开机没蓝牙设备没法用呢！开机直接懵逼了。

第二天才想过来，有扩展坞的话，直接用 usb 的键盘和鼠标连接也是可以的...

然后在咸鱼花了 100 元，配了个罗技 K380 + M240，作为蓝牙设备使用。

还没到货，后面会补图。

之前同事用 k380 用了几年一直没换，淘宝京东的出货量也很大，想必质量应该是可以的。

使用我的 M2Air 迁移助手迁移的时候，光用户文稿等信息就 200G+，直接迁不过去。

索性就从头开始安装了，只把一些系统设置迁移过去了

后续就作为在家里的主力机器使用，公司写了代码或者文章，没写完的再回家接着写。

因为主机很小，线也不多，显得桌面也比较干净了。

显示器的话用的是很多年前的微星 2k 显示器，估计近期也不会换了，等有预算之后，可以换个 4K的红米显示器（如果支持雷电口的话）

以前的冲动消费太多了，这次仔细思考之后，3749 真是很有性价比的生产力工具了。（玩炉石也是极😉）

现在每天敲代码和写文章，基本也点习惯的痕迹了，希望能保持下去吧

Nuxt3全栈开发 · $fetch、useFetch、useAsyncData 你用对了吗？

Wed, 27 Nov 2024 00:00:00 GMT

Nuxt3 中有三种获取数据的方式，看起来有点绕，那实际使用中有什么区别，应该怎样使用呢？

$fetch

$fetch 基于 ofetch ，ofetch 是一个类似 axios 的请求库，可以运行在 node、浏览器、workers 上。

所以它的用法类似原生 fetch 、axios，在 Nuxt3 中全局可用。

在 app 中直接向 server 内的 api 发起请求
在 app 中向其他服务发出请求
在 server 的一个接口中向另一个接口请求
在 server 的一个接口中向其他服务发出请求

总之，是一个底层的请求库。

用它是最简单的方法。

但 Nuxt 是一个可以在服务器和客户端两个环境下运行同构代码的框架，如果在 setup 中使用 $fetch 来获取数据，可能会导致执行两次，一次在服务器上由 nitro 渲染 html 时，另一次是在客户端水合时。

所以水合是一个必须要理解的过程：

当在浏览器打开一个页面时，首先会在服务端渲染（SSR)，渲染后的完整 html 代码会被发送到客户端。此时已经在服务端拿到请求的数据了，所以客户端收到 HTML后，用户已经能够看到内容。

对比单页应用（SPA），浏览器只是加载了一个带有根元素的的 html 页面，所以此时页面是空白的，还需要在加载完相关 JS文件后，由 JS 去插入内容。所以单页应用只要在根元素 div id = app 里写点内容（如loading、骨架），就会早于实际内容出现，达到不白屏的效果。

回到 Nuxt ，用户看到内容后，此时页面还无法交互，因为仅仅是渲染了 HTML，Vue 相关的逻辑还在 JS 里，需要下载和执行。

下载和执行时被 Vue 接管 HTML 的过程就叫水合，水合后界面就可以响应用户的交互了。

有了渲染方式的差异，才会有其他的请求方式来契合这种渲染方式。

useAsyncData

从 vue2 到 vue3，我们都知道多了个选项式和组合式的区别。

选项式中通常把功能集中在一个组件或函数中，每个组件都有 data、methods，组件内定义属性都会暴漏在函数内部的 this 上，指向当前实例。它的特点是，不关心响应式细节，强制按照选项来组织代码，你的后端同事看了 Vue 之后都表示很简单。

而组合式（composable）的核心思想是直接在函数作用于内定义响应式变量，要比选项式自由和高效的多。

所以 Vue3 的代码中，经常可以看到 UseXXXX 这类的函数，其内部就包含响应式变量，也就类似选项式代码中的 data 和 method。

所以其内部的响应式变量发生变化时，通常会有一个对应的逻辑随之发生变化，可能是另一个响应式变量，也可能是与之对应的Template

所以 useAsyncData 这个 composable ，也有类似的功能和效果。

const { data, error, clear, status, refresh } = await useAsyncData('users', () => myGetFunction('users'))

useAsyncData 第一个参数是唯一键，用于缓存第二个参数的响应。

所以用 useAsyncData 时，在 SSR 时和在 水合 时，不会发生两次重复的请求。可以保证渲染的一致性。

其次，因为第二个参数只是一个获取数据的匿名函数，所以你可以用它来请求任意的服务，比如你用了其他 CMS服务来管理数据，这时候就应该使用 useAsyncData。

这东西竟然有五个返回值，看看都有啥用，怎么就响应式了。

data、error、status 这三个值，都是 Vue 的引用（ Vue refs accessible），也就是说类似于你用 ref 提前定义好了一样：

const data = ref()
const error = ref()
const status = ref('idle') // 还没请求

const fetchData = async () => {
	status.value = 'pendding'
	const data = await fetch('xxxx').catch( err => {
		error.value = err
		status.value = 'error'
	})
	...
	data.value = res.data
	status.value = 'success'
}

这样看能明白了吧。

data 就是我们接收返回后的数据的 Ref 引用，error 同理，status 则是类似于在 Vue2 中使用一个 isFetch 变量去管理 loading 状态。

也可以直接给 data 重命名一下：

const { data: userList, error, clear, status, refresh } = await useAsyncData('users', () => myGetFunction('users'))

不过要注意，这个 data.value 是什么，和第二个参数返回的数据是什么有关，比如你的接口固定返回：

{
	code: 200,
	data: [],
	msg: 'ok',
}

那要想取得列表渲染要用的数据，应该是 userList.value?.data

因为渲染方式的特点，useAsyncData 还可以传入第三个参数 options 来控制其行为。

lazy

默认情况下，页面使用了 useAsyncData 来获取数据，这个 composable 会等待异步函数的解析，然后再导航到新的页面。

解析会耗时，所以你的导航动作就会有延迟，给人一种：点了，但是没立马动起来的迟滞感。

lazy 选项可以使其忽略异步函数的解析。

const { data: userList, error, clear, status, refresh } = await useAsyncData('users', () => myGetFunction('users'), { lazy: true })

此时，当你点击进入一个新的页面时，导航不会被阻塞，但进入后内容可能还没拿到，所以需要使用 status 来加载 loading、骨架组件。

我觉得应该没人想在点击后阻塞导航吧，所以这个 lazy 建议一直开启。

server

上一篇关于在 Nuxt 中使用 Prisma 的文章里，我提到了本地有个 dev.db ，线上也有一个 prod.db 。

两个数据库里存的东西肯定是不一样嘛，因为本地需要测试。所以我本地的 userList 里是张三，线上的 userList 是李四。

但在 Nuxt 打包时，会 prerender，预渲染！（我需要本地打包的）

也就是先把接口请求一遍，把真实的 HTML 先给组装好，并且还有缓存。因为是为了 SEO，方便搜索引擎快速抓取到页面的内容。

于是，在线上打开用户列表页时，我的张三被显示出来了，因为他就是 HTML 里的内容。

这个时候就需要另一个选项： server

当设置 server: false 时，第一次渲染就不会去请求数据，也就是会渲染出一个空的用户列表页。

const { data: userList, error, clear, status, refresh } = await useAsyncData('users', () => myGetFunction('users'), { lazy: true, server: false })

watch

看到这，我也没看出来 useAsyncData 响应个啥了啊，不就是帮我省下了创建接收数据的 ref 和管理状态的 ref 的功夫？

那我们再把获取列表这个场景丰富一下。

用户多了，有分页了，应该怎么处理？

const page = ref(1)
const changePage = () => {
	myFetchData()
}

如果再加个类型的筛选，日期的筛选等等一切和重新获取数据相关的响应式变量，都要写同样的代码。

所以 useAsyncData 支持直接 watch 响应式变量：

const page = ref(1)
const { data: userList, error, clear, status, refresh } = await useAsyncData('users', () => myGetFunction('users'), { lazy: true, watch: [page, tags] })

当 page 发生变化时，useAsyncData 就会重新执行它的 handler ，做到刷新数据。

代码量又减少了不少

其他选项

和 vue 的 watch 相比，useAsyncData 也有一个 immediate 选项，只不过它默认是 true ，你可以设置为 false 来阻止立即触发请求。

还有一种场景，使用一个接口获取一组比较大的数据比如文章时，有时候不需要文章的内容，每次都传输内容的话，数据量太大了，影响传输速度。

可以使用 pick 选项，选取指定的键：pick: ["title", "description"]

还有 deep 选项，默认为 true ，如果不需要深度深度响应时，可以设置为 false 以提高性能。

其他选项就不一一介绍了，我直接放在这里，后续发现比较有用的场景，再来分享。

type AsyncDataOptions<DataT> = {
  server?: boolean
  lazy?: boolean
  immediate?: boolean
  deep?: boolean
  dedupe?: 'cancel' | 'defer'
  default?: () => DataT | Ref<DataT> | null
  transform?: (input: DataT) => DataT | Promise<DataT>
  pick?: string[]
  watch?: WatchSource[]
  getCachedData?: (key: string, nuxtApp: NuxtApp) => DataT
}

现在可以确定，useAsyncData 可以帮助缓存数据，防止多次请求，保证渲染的一致性。提供响应式的 data、error、status 来完成页面的渲染，同时提供一些选项来控制其行为。

最后再来捋一捋什么场景下使用什么选项的问题：

PS：这图我在 Youtube 刷到的，但是没截屏，所以凭借印象又画了一遍

那 useFetch 还有什么活能整吗？

useFetch

useFetch 的整活就像是：

虽然在 script 需要使用 .value 获取响应式数据，但 template 中不需要，因为 Vue 帮你处理了。

以前 props 解构会失去响应式，现在（3.5+）解构也能直接用了。

是的，它就是个语法糖一样，是 useAsyncData 和 $fetch 的包装器。

它不用传第一个 key 值，会根据 url 和选项自动生成，并且可以推断 API 的响应类型。

同时有着和 useAsyncData 一样的第三个参数（选项），但做了一些增强。

还是拿刚才获取用户列表的场景举例，我们监听 page、tags，变化时会再次请求。

在 useFetch 中可以再进一步：

const page = ref(1)
const { data: userList, error, clear, status, refresh } = await useFetch('/api/user/list', { page }, { lazy: true })

我们只需要传入 page 这个响应式变量，useFetch 就会追踪到这个响应式变量。

类似 watch 和 watchEffect。一个需要显式的传入，一个会自动的追踪。

但是这里要注意：{ page } 等价于 { page: page }，而不是 { page: page.value }

page.value 只是一个值！ 所以要传入的是 page 这个 ref对象

使用 useFetch 后代码被进一步简化。

所以在思考使用 useFetch 还是 $fetch 来进行接口请求时就十分明了了：

一般基于用户的交互才去做出反应的，就用 $fetch 就可以。

如果基于页面状态需要重复获取数据的，就用 useFetch 。

但刚才也强调了，传入的是一个 ref对象 才会时 useFetch 正常的响应式的自动请求，所以如果是想统一请求方式，也可以选择直接传值给 useFetch ，这样他就像一个普通的增强版 $fetch 一样了。

但 useFetch 返回的值还是个响应式的，使用 $fetch 的场景很多都不需要返回值再触发其他响应，所以显得有些"多余"。

怎么取舍就看自己了。

最佳实践

我在项目中以使用 useFetch为主 , 那怎么封装 useFetch 用起来才最顺手呢？

经过我自己的使用，以及搜索多个关于 useFetch 的使用。最后在最少三个博客站内发现了同样的封装代码，究竟谁是作者我也不清楚，代码里也没有说明，这里直接贴给大家，再分析如何使用。

composables/useHttp.ts

import type {FetchError, FetchResponse, SearchParameters} from 'ofetch';
import {hash} from 'ohash';
import type {AsyncData, UseFetchOptions} from '#app';
import type {KeysOf} from '#app/composables/asyncData';
type UrlType = string | Request | Ref<string | Request> | (() => string | Request);

type HttpOption<T> = UseFetchOptions<ResOptions<T>, T, KeysOf<T>, any>;
interface ResOptions<T> {
    data: T;
    code: number;
    message: boolean;
    err?: string[];
}

function handleError<T>(
    _method: string | undefined,
    _response: FetchResponse<ResOptions<T>> & FetchResponse<any>,
) {
    // Implement error handling logic here
    if (_response?._data?.statusCode === 401) { 
      // setUser('')
    }
    console.error(`[useHttp] [error] ${_method}:`, _response);
}

function checkRef(obj: Record<string, any>) {
    return Object.keys(obj).some(key => isRef(obj[key]));
}

function fetch<T>(url: UrlType, opts: HttpOption<T>): AsyncData<ResOptions<T>, FetchError<ResOptions<T>>> {
    // Check the `key` option
    const { key, params, watch } = opts;
    if (!key && ((params && checkRef(params)) || (watch && checkRef(watch))))
        console.error('\x1B[31m%s\x1B[0m %s', '[useHttp] [error]', 'The `key` option is required when `params` or `watch` has ref properties, please set a unique key for the current request.');

    const options = opts as UseFetchOptions<ResOptions<T>>;
    options.lazy = options.lazy ?? true;

    // const { baseUrl } = useRuntimeConfig().public;

    return useFetch<ResOptions<T>>(url, {
        // Request interception
        onRequest({ options }) {
            // options.baseURL = baseUrl;
            // Set the base URL
        },
        // Response interception
        onResponse(_context) {
            // Handle the response
        },
        // Error interception
        onResponseError({ response, options: { method } }) {
            handleError<T>(method, response);
        },
        // Set the cache key
        key: key ?? hash(['api-fetch', url, JSON.stringify({ method: options.method, params: options.params })]),
        // Merge the options
        ...options,
    }) as AsyncData<ResOptions<T>, FetchError<ResOptions<T>>>;
}

export const $http = {
    get: <T>(url: UrlType, params?: SearchParameters, option?: HttpOption<T>) => {
        return fetch<T>(url, { method: 'get', params, ...option });
    },

    post: <T>(url: UrlType, body?: RequestInit['body'] | Record<string, any>, option?: HttpOption<T>) => {
        return fetch<T>(url, { method: 'post', body, ...option });
    }
};

export default function UseHttp() {
    return {
        $http,
    };
}

总体封装的很简单，基本没啥看不懂的点，细节还是要自己去扩充。

其中 ResOptions 需要根据自己的返回值类型修改

handleError 负责在 onResponseError 时处理错误。

onRequest 可以自行添加比如 baseUrl 、自定义 header 等。

lazy 默认开启是最好用的，loading（status）状态自己维护

使用时的几种情况大概是这样：

基于请求传入的 ref 对象，自动重新请求
watch 其他 ref 对象，以重新请求
不需要马上在页面中展示的，server: false
除此之外基本用默认配置就可以了

// hash('memo-list-search')
const { data: memoList, error, status } = await $http.get('/api/v1/memo/list', { page: 1, size: 100 }, { key: hash('memo-list-search'), server: false, watch: [user, refreshKey] })

const { data: memoList, error, status } = await $http.get('/api/v1/memo/list', { page, size: 100 }, { key: hash('memo-list-search'), server: false })

重点是 key 。

如果需要响应式请求，则必须传入 key 值，传入的对象会被 checkRef(params) 检测是不是 Ref ，其他选项（options）还是可以正常传入。

虽然代码里有个默认的 key 值，只是会打印一个错误，但这个 key 还是建议手动传入，以免造成key值重复时，发生错误的缓存问题。

虽然这里封装了 handleError ，但实际上我没发现没什么用，原因是我用的 primevue/toast 目前不能套在 useFetch 这个 composable 中使用。我基本尝试了 github 和 stackoverflow 能搜到的几种方式都没有奏效。

而发生错误时提示出来基本是必做的一个动作，所以我只能把 show error toast 这个动作，放在了另一个 composable （useErrorDispose）中，在使用 $http 的 vue 文件中，使用这个 useErrorDispose 处理 error.value，以及本地的缓存信息。也算是完成了我的需求。

另外，请求时，（公司中）一般会设置 header 中携带 token，但实际上没有比 cookie 更好用

{
    httpOnly: true,
    sameSite: isProd ? 'strict' : 'lax',
    maxAge: 2592000, // maxAge 优先级高， expires 受客户端时间的影响
    secure: true,
    domain: 'abc.com',
  }

这样设置后，也能节省不少（操作 localstorage 的）代码，还比使用 localstorage 存储 token 再放在 header 上更安全一些。

而 nuxt（nitro）中操作 Cookie 也是十分简单的，可以自行了解一下。

总结

以上就是本人在使用 $fetch、useFetch、useAsyncData时的一些经验分享，希望能够帮助到你。

同时，如果你有更多的经验，也希望在评论区指正文中的错误，让大家学到更多

更多 Nuxt 最新的全栈开发内容，欢迎关注「早早集市」

Nuxt3全栈开发 · 如何使用Prisma+Sqlite

Tue, 26 Nov 2024 00:00:00 GMT

想要在 Nuxt3 中使用 Sqlite 非常简单，但重点是如何管理表结构的变更。

Nuxt3官方提供了配置，可以直接开启数据库，默认就是sqlite，数据库文件会存储在.data/ 目录下。

https://db0.unjs.io/connectors/sqlite

nitro: {
    experimental: {
      database: true
    },
    database: {
      default: {
        connector: 'sqlite',
        options: {
          path: '/blog',
          name: 'blog.db'
        }
      }
    },
    devDatabase: {
      default: {
        connector: 'sqlite',
        options: {
          path: '/Users/your_name/code/abc/databases/blog',
          name: 'blog.db'
        }
      }
    }
  },

但是后续的表结构的更新、新增、删除等操作如何和线上同步就是一个大问题了。

所以对于单机部署的博客来说，还是用上Prisma省心。

安装及配置

没有用到官方的 @prisma/nuxt ，因为一开始装上报错了。

Environment variables loaded from .env
Prisma schema loaded from prisma/schema.prisma
Error: 
The "path" argument must be of type string. Received undefined

后来单独安装了 prisma 和 @prisma/client 之后，发现有同样的问题。我也懒得再来一遍来，就按 prisma 文档里流程接入。总之，运行 prisma 相关命令时添加上 npx prisma 就可以了。

npm i prisma -D

npm i @prisma/client

npx prisma init

初始化完成后，会生成一个 prisma 目录，里面有一个 dev.db 和 schema.prisma。

dev.db 是本地的数据库文件。如果你恰好也用 VS Code 的话，可以用 SQLite3 Editor 这个免费的插件管理

https://github.com/yy0931/sqlite3-editor

好用的话别忘了给人家点个赞

schema.prisma 就是我们代码和数据库之间的“桥梁”，里面定义了：

client：客户端配置
db：数据库配置，使用什么数据库，链接地址
model：所有表结构

client 里的 provider 是一个固定的值 prisma-client-js ，还有一个 binaryTargets 比较有用。

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-3.0.x"]
}

native 就是本机的环境，第二个值我配的是服务器上的环境，配好这个参数后，prisma/client 里会生成对应的二进制文件，会被打包上去。（因为我这个项目是本地打包）如果你是线上打包的话，那 native 其实就是你得线上服务器环境了。

db 主要是指定使用的数据库，以及地址。

这里我用 Sqlite，所以我这样配置：

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

其中 env("DATABASE_URL") 是要读取你根目录下的 .env 文件里的 DATABASE_URL，所以说在部署时，要把 env文件 也发上去。

但 Nuxt3 里不推荐用 env文件 管理环境变量，因为它本身要支持更多的部署环境，所以这里可以用其他方式来设置。

如果用 pm2 启动 node 服务（Nuxt output），那就可以在 ecosystem.config.cjs，设置环境变量

module.exports = {
  apps: [
    {
      name: 'Blog',
      port: '4577',
      exec_mode: 'fork',
      // instances: 'max',
      script: './server/index.mjs',
      // interpreter: '~/.bun/bin/bun',
      env: {
        NODE_ENV: 'production',
      },
      env_production: {
        NODE_ENV: 'production',
        DATABASE_URL: "file:/your_path/data1/dbs/blog.db"
      }
    }
  ]
}

如果用 docker / docker-compose 同样的也是在 Dockerfile、docker-compose.yml 里配置好。

model 里就是定义表结构。以一个 user 表为例

model User {
  id           Int           @id @default(autoincrement())
  email        String?       @unique
  username     String        @unique
  nickname     String?
  password     String
  avatar_url   String?
  articles     Articles[]

  @@map("b_users")
}

model User ，这里的 User 会在其他的 model 中使用，如 user_info User ：

model Articles {
  id         Int        @id @default(autoincrement())
  uid        String     @unique
  title      String
  tags       String     @default("[]")
  create_ts  DateTime   @default(now())
  updated_ts DateTime   @updatedAt
  user_id    Int
  user_info  User       @relation(fields: [user_id], references: [id], onDelete: NoAction)

  @@map("b_articles")
}

字段、类型、说明这些规则就不说了，看看文档就能懂。这里 user 和 article 是一对多关系，每个 article 只有一个 user，一个 user 可以有多个 article。

这个 user_info 在表结构中不会存在，只是 prisma 会用到，所以表里的字段是 user_info 上面的那些。

这个 User，同样也会在使用 prisma 进行查询时使用，比如：

await prisma.user.findMany(...some options )

如果要给 User 重新定义个名字，就使用 @@map ，这个名字（b_users）就是数据库真正的表名

初始化和使用

定义好自己配置、表结构后，我们希望把定义好的结构同步到 dev.db 里去，此时 dev.db 是空的。

npx prisma migrate dev --name init

migrate 是迁移的命令，dev 是在本地开发时表结构发生表更时生成一个迁移文件的命令。

生成的迁移文件会在 prisma/migrations 中 2024111100000_init/migration.sql 。

生成会自动执行一下 prisma generate，此命令会安装 @prisma/client并根据我们定义的模型，生成 client API 。

这就是为什么刚才的代码能顺利运行，并且提示的信息还特别全的原因（提供了完整的 TS 代码提示）：

await prisma.user.findMany(...some options )

此时我们就可以使用 prisma/client 的 API 在代码中进行增删改查操作了。

在此之前，如果还没有一个 prisma 实例，可以像我一样在 server 目录中创建一个 prisma.ts

import { PrismaClient } from '@prisma/client'

const prismaClientSingleton = () => {
  return new PrismaClient()
}

declare const globalThis: {
  prismaGlobal: ReturnType<typeof prismaClientSingleton>;
} & typeof global;

const prisma = globalThis.prismaGlobal ?? prismaClientSingleton()

export default prisma

if (process.env.NODE_ENV !== 'production') globalThis.prismaGlobal = prisma

然后在 server/api/v1/user 中（没有的话需要创建），新建一个接口文件 login.post.ts

此时 Nuxt 中会出现一个 POST 接口：/api/v1/user/login ,（你可以在页面中或其他 api工具中调用测试一下）

然后在 login.post.ts 中引入 prisma 进行使用。当然，如果你用了官方的 module，这里直接使用 prisma 实例就可以了。


import prisma from '~/server/prisma'

export default defineEventHandler(async (event) => {
	// useSafeValidatedBody
  const body = await readBody(event)
  const { nuxtSecretKey, jwtSecret } = useRuntimeConfig(event)
  const { username, password } = body
  const secret = new TextEncoder().encode(jwtSecret)
  const user = await prisma.user.findUnique({
    where: {
      username
    }
  })

  return {
    data: user,
    msg: '登录成功'
  }
})

这里仅仅演示一下 client api 的使用。然后在 nuxt3 中，使用 $fetch 、useAsyncData 、useFetch 进行调用即可。

表结构变更和同步

在开发阶段，表结构很有可能会变动。

这种情况下，只需要修改 prisma.schema 的 model 定义，然后再使用 migrate dev ，生成一条迁移文件。

npx prisma migrate dev

比如我的初始 User 是这样的（init/migration.sql）

-- CreateTable
CREATE TABLE "User" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "email" TEXT NOT NULL,
    "name" TEXT
);

-- CreateIndex
CREATE UNIQUE INDEX "User_email_key" ON "User"("email");

然后我发现字段不够，或者要改，于是修改 model 后，运行 migrate dev , 又生成了一条 migration.sql

/*
  Warnings:

  - Added the required column `password` to the `User` table without a default value. This is not possible if the table is not empty.

*/
-- RedefineTables
PRAGMA foreign_keys=OFF;
CREATE TABLE "new_User" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "email" TEXT NOT NULL,
    "name" TEXT,
    "password" TEXT NOT NULL,
    "role" TEXT NOT NULL DEFAULT 'user'
);
INSERT INTO "new_User" ("email", "id", "name") SELECT "email", "id", "name" FROM "User";
DROP TABLE "User";
ALTER TABLE "new_User" RENAME TO "User";
CREATE UNIQUE INDEX "User_email_key" ON "User"("email");
PRAGMA foreign_key_check;
PRAGMA foreign_keys=ON;

我又加了 password、role，它的做法是新建一个 new_user 表，把原来的表的内容插入进去，然后把新的表名改一下。同时上方有提醒我加了一个 password ，但又不能为空，如果原表有数据的话，就会有问题了。这个需要注意一下。

此时，把新的表结构同步到线上的命令，使用的是：prisma migrate deploy

如果数据库是空的、新的，那本地一直用 migrate dev 生成变更，线上一直用 migrate deploy 就能一直同步（目前我没发现问题）

但有一些情况是，项目可能是老的，数据库也已经存在。此时就需要 prisma 的其他命令，如 push 、pull

设置基线

如果已经有数据库了，数据库无法被重置。

就要用到基线。只要不是刚接入数据库，可以都算这种情况。

先把现有的表结构拉下来。官方称之为内省/反省（==Introspection==）

prisma db pull

拉下来的结果，就和初始化时自己写 model 一样，prisma.schema 里会生成一堆和现有数据库对应的表结构。

如果已经有了 prisma/migrations 文件夹，请删除、移动、重命名或备份此文件夹

新建migrations文件夹，新增一个 0_init 目录，注意：前缀是必须的！,正常使用时是按时间戳排序的，这里需要重建一个基线，所以以 0_ 开头。

mkdir -p prisma/migrations/0_init

使用migrate diff生成一份migration.sql。

个人理解：生成一份和当前数据库差异sql，也就是运行这个sql后可以达到目前这个数据库的结构。

npx prisma migrate diff \  
--from-empty \  
--to-schema-datamodel prisma/schema.prisma \  
--script > prisma/migrations/0_init/migration.sql

resolve 应用这个差异

个人理解：应用意为已经执行过了，相当于抹平了历史记录，从现在开始的改动就是基于当前数据库结构的变更了。

npx prisma migrate resolve --applied 0_init

线上数据库同理。

后续有表结构的改动，就使用migrate dev来维护就可以了

npx prisma migrate dev

部署到服务器上时，我是把 prisma 也直接push (git)到项目打包后的目录下了，同步表结构只需要:

npx prisma migrate deploy

不知道关于这部分，我有没有讲清楚？

总结

以上就是在 Nuxt3 中使用 prisma 管理 Sqlite 的一些经验分享。

后续还会有深入和具体的 Nuxt3 全栈项目内的使用，完全使用 Nuxt 的 Server 能力开发接口等内容还在编写中～

欢迎关注「早早集市」

Nuxt3全栈开发 · 配置篇

Tue, 19 Nov 2024 00:00:00 GMT

最近在用Nuxt3全栈开发个人博客，踩了不少小坑，这篇文章总结一下。

依赖库及博客主要功能

先来介绍一下我用到了哪些 Nuxt3 的相关生态及对应的功能。

@nuxtjs/color-mode 颜色模式：白天（light）、黑夜（dark）、系统（system）三者切换
@nuxt/content 展示文章，基于mdc，可以使用自定义组件渲染markdown，支持 front matter
@nuxtjs/tailwindcss 样式。以及配合 @tailwindcss/typography 自定义markdown主题
@primevue/nuxt-module 组件库。
@nuxt/image 图片
@nuxt/icon 图标。配合 iconify ，我目前用的图标主要是 @iconify-json/icon-park-outline
@nuxt/robots SEO
@nuxt/mdc 解析动态（类型Memos/朋友圈/X）展示。和文章有一致的表现，也可以通过tailwindcss自定义样式
prisma 管理数据库（sqlite3）
gitea 管理代码仓库（私有）。以及使用workflows自动部署

基于这些库逐步使用和功能的逐渐实现，分享一下使用经验。

如果没有刻意提到的安装方式，则默认都是用 npx nuxi@latest module add xxxx 进行安装。

如果没有表明在何处配置，则默认是在 nuxt.config.ts 的顶级

如果代码中变量明显没有引入，则是使用了 Nuxt3 的 auto imports

颜色模式

colorMode: {
    preference: 'system', // default value of $colorMode.preference
    fallback: 'light', // fallback value if not system preference found
    // hid: 'nuxt-color-mode-script',
    // globalName: '__NUXT_COLOR_MODE__',
    // componentName: 'ColorScheme',
    // classPrefix: '',
    // classSuffix: '-mode',
    // storage: 'localStorage', // or 'sessionStorage' or 'cookie'
    // storageKey: 'nuxt-color-mode'
  },

有三种模式：light dark system ，默认为 system 根据系统模式来自动设置浅色或深色

切换模式时：

const colorMode = useColorMode()
const index = ref(modes.indexOf(colorMode.preference))
// 用来显示不同图标
const modes = ['system', 'light', 'dark']

const modeIcon = computed( () => {
	switch ...
	case ...
})

function toggleColorMode() {
  colorMode.preference = modes[(++index.value) % modes.length]
}

配合组件库 primevue 的配置

primevue: {
    importTheme: { from: '~/primevue/theme.ts' },
    // usePrimeVue: false
  },

theme.ts 如下


import { definePreset } from '@primevue/themes';
import Aura from '@primevue/themes/aura';


const Noir = definePreset(Aura, {
  semantic: {
      primary: {
	      ...
      },
      colorScheme: {
        light: { ... }
        dark: { ... }
      }
  },
  components: {
    button: {
      ...
    }
  }
});


export default {
    preset: Noir,
    options: {
        darkModeSelector:'.dark-mode'
    }
};

设置 darkModeSelector 为 .dark-mode。使用colorMode切换时，会自动切换 html 的 class

解析Markdown文件

content: {
    documentDriven: {
      injectPage: false
    },
    highlight: {
      theme: 'github-light',
      langs: ['typescript', 'vue', 'javascript', 'go', 'shell', 'bash', 'yaml', 'markdown', 'json', 'html', 'ts', 'js']
    },
    sources: {
      obsidian: {
        prefix: '/obsidian', // All contents inside this source will be prefixed with `/fa`
        driver: 'fs',
        base: `/Users/your_name/code/notion/blog` // Path for source directory
      },
    }
  },

documentDriven 的 injectPage 是为了解决一个警告信息

[@nuxt/content 09:52:13] Using <NuxtLayout> inside app.vue will cause unwanted layout shifting in your application.

原因是，原代码从 pages/[slug].vue 改为 pages/post/[slug].vue 导致报错。

以下是搜索时找到的相关issue

NuxtLayout warn vs documentation #15240

nuxt-blog-starter

highlight 是配置代码块高亮的，内部使用的是 Shiki，同时和 color-mode 兼容，可以查看更多官方文档

sources 是核心配置，

官方的默认配置是 base: resolve(__dirname, 'content') , 即从当前项目下的content内读取md文件，我直接改成了自己本地的一个目录。

启动项目时，会读取并监听该目录下的所有md文件，并有一个忽略规则（开头为 . 或 - 的），然后会解析并缓存到 .nuxt 内，dev 模式下就是从 .nuxt 中直接拿缓存数据，所以有一些奇怪的问题可以通过删除 .nuxt 并重新运行可以解决。

当然这个配置也决定了必须带着 .nuxt 目录才能正常打包。

只靠 @nuxt/content 解析出的文章还没眼看，需要借助 @tailwindcss/typography。

使用前：

使用（并自定义）后：

markdown 被解析为 p 、a 、code 、h1 、h2、img、strong 等这些标签，而在 @nuxt/content 中，使用对应的 ProseA、ProseH1 组件进行渲染。

并且支持自己编写然后覆盖这些组件预设，在 components/content 目录下新建一个同名的组件，如 ProseA.vue ：

<template>
  <NuxtLink :href="props.href" :target="props.target"
    class="font-bold border-b-2 border-dashed border-zinc-600 hover:border-solid hover:border-zinc-900 dark:border-zinc-300 dark:hover:border-zinc-100">
    <slot />
  </NuxtLink>
</template>

<script setup lang="ts">
import type { PropType } from 'vue'

const props = defineProps({
  href: {
    type: String,
    default: ''
  },
  target: {
    type: String as PropType<'_blank' | '_parent' | '_self' | '_top' | (string & object) | null | undefined>,
    default: '_blank',
    required: false
  }
})
</script>

这里我把他的默认打开方式改为了 _blank ，并自定义了功能和样式。其他组件同理，都是可以自定义的。查看NuxtContent中支持的组件

同样的可以基于 typography 在顶层修改其样式。

import typography from '@tailwindcss/typography'
/** @type {import('tailwindcss').Config} */
export default {
  content: [],
  plugins: [typography()],
  theme: {
    extend: {
      typography: (theme) => ({
        DEFAULT: {
          css: {
            code: {
              // backgroundColor: theme('colors.gray.100'),
              // color: theme('colors.orange.400'),
              fontWeight: 'normal',
              marginLeft: theme('spacing.1'),
              marginRight: theme('spacing.1'),
              paddingLeft: theme('spacing.2'),
              paddingRight: theme('spacing.2'),
              paddingTop: '1px',
              paddingBottom: '1px',
              borderRadius: '2px',
              '&::before': {
                content: `''!important`
              },
              '&::after': {
                content: `''!important`
              }
            },
            p: {
              lineHeight: theme('lineHeight.loose')
            },
            pre: {
              // paddingBottom: 0,
              // paddingTop: 0,
              '& > code': {
                color: theme('colors.gray.900'),
                backgroundColor: 'transparent'
              }
            },
            a: {
              textDecoration: 'none'
            },
            img: {
              marginTop: 0,
              marginBottom: 0,
            }
          }
        }
      })
    },
  },
}

这里我建议只改大小间距等属性，颜色相关的我放在了其他地方管理，比如 assets/tailwind.css：

/* 针对page的prose颜色配置 */
.mdc-page-prose {
  @apply prose prose-zinc prose-pre:bg-gray-100 dark:prose-pre:bg-zinc-400 dark:text-zinc-200 dark:prose-strong:text-zinc-200 prose-code:bg-zinc-200 dark:prose-code:bg-zinc-200 prose-code:text-zinc-800 dark:prose-blockquote:text-zinc-300
}

因为后面还涉及到动态的展示，动态也是基于mdc渲染的，也共用一套样式，那我再定义一个 .mac-memo-prose 可能会更灵活一些。

解析Markdown字符串

@nuxtjs/mdc 提供了 MDC 组件来渲染md字符串，添加此模块后即可使用：

<MDC :value="content" tag="section" class="mdc-memo-prose prose"/>

一开始我是没发现mdc可以直接使用。在搜github的issue时，早期的nuxt版本中，大家都是手动引入包内的解析函数😏 这就是用的晚的好处吧～

样式表现和文章解析出来一模一样，如果想自定义，就用 mdc-memo-prose 去添加。

如果要使用一个自定义组件（Mtag.vue）时：

::mtag
是实打实
::

在 components/global 目录下新建 Mtag.vue ：

<template>
  <Tag class="h-6 mr-2"><slot></slot></Tag>
</template>

此 Mtag 中使用的是 primevue 中的 Tag 组件，这也就意味着仅靠输入一些简单的语法，就实现了无限的组件呈现

图片、图标、SEO

图片使用 @nuxt/image 模块

如果仅使用 src 属性，NuxtImg 会输出原始的 img 标签。

它提供了 sizes、placeholder（占位符）、preset、format（指定格式）、quality（图片质量）、loading（懒加载）、preload（预加载）等非常多的配置，非常省事、好用。

这里没有什么特殊用法，所以可以直接查看所有配置。

图片使用 @nuxt/icon 模块

搭配 icon 库(@iconify-json/icon-park-outline)使用：

npm i -D @iconify-json/icon-park-outline

直接使用：

<Icon name="icon-park-outline:wechat"></Icon>

修改大小 ( 修改颜色直接改 style color: xxx )：

<Icon name="icon-park-outline:wechat" size="1.5em"></Icon>

如果要替换掉 primevue 的 icon：

<Button severity="parimary" size="small">
	<Icon name="icon-park-outline:wechat" slot="icon"></Icon>
</Button>

SEO相关

最直接的办法就是，打开控制台，找到 Lighthouse , 开始分析即可

看看哪里加载慢，SEO里提示什么可以优化，比如没有 robots，那就加入模块 @nuxt/robots 就会自动帮你做好了。

其他的就是注意 img 的 alt 有没有写，第三方 js/css 设置 sync defer，页面绘制时偏移等等

header 信息，可以用 useHead 轻松设置

useHead({
  title: '早早集市｜博客站',
  meta: [
    {
      name: 'description',
      content: 'https://blog.zzao.club',
    },
    {
      name: 'keywords',
      content: '',
    },
  ],
})

prisma 和 gitea

这两篇太长了，我决定分出去两篇，下次再发！

结语

作为一个展示为主的博客，前端使用这些模块、库已经够用了，但作为一个全栈框架，后端 Nitro 也是要玩一玩的，所以后续的开发计划偏向于后端。

登录、注册、用户分组
文章、动态支持评论
文章、动态支持分享（图片、短链接）
图片上传（cos）

其中涉及到大量对 Nitro 的探索，鉴权、中间件、数据库等等。这也是后面文章输出的重点方向，即 Nuxt3 的全栈开发。

👏👏欢迎关注「早早集市」

Nuxt3中使用prisma binaryTargets多环境配置

Fri, 15 Nov 2024 00:00:00 GMT

场景：本地使用macos开发，服务器是Debian12，打包时需要本地打包再上传

schema.prisma 配置 binaryTargets 字段，本地正常使用，打包后会自动区分环境

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "debian-openssl-3.0.x"]
}

可以看到 generate 时生成的目录下有俩 .node 二进制包，分别对应 binaryTargets 两个环境

另外：不要把output指定到node_modules外面，使用默认配置即可，这样打包后的文件里使用了 __dirname 导致会报错。此条解决办法来自github issues ，有更好的办法，欢迎留言

[nuxt] [request error] [unhandled] [500] __dirname is not defined in ES module scope

版本管理工具

Thu, 14 Nov 2024 00:00:00 GMT

目前我的全部项目的版本管理都在使用 unjs/changelogen

无需安装，也无需配置，只需要增加几个 scripts 即可

具体细节和版本号声明请看：语义化版本控制说明

基于Hono和Satori的后端生成SVG图片简易方案

Thu, 07 Nov 2024 00:00:00 GMT

Satori （Vercel的）是一个可以把HTML+CSS生成SVG的一个库。

通常提到把HTML转为图片，都会想到 html2canvas 、html-to-image这类的库，但这类库需要借助浏览器环境，比如各种卡片类网站的导出功能（css特性支持有限）。但如果是多端都有生成需求，或者要实现更便捷的获取方式，就得考虑放在后端去实现。

而Satori只需要接收JSX元素就可以计算得出SVG内容，不需要在前端就可以实现。重要的是，文字的字体也会保留，文字直接被解析成了path！

虽然Satori不保证SVG和浏览器呈现的 HTML 100%匹配，但我觉得仅是脱离浏览器和保留了相当一部分css属性的支持，就足够产生无限的想象。

功能构思

要实现的功能很简单，前端网站上有个文字转卡片的界面，支持保存主题和样式的预设到后端，然后用户在其他地方调接口就能到图片。

前端页面上可以自定义一套样式，包括背景，渐变，flex布局，阴影等等一切 Satori 支持的css 。
前端的html框架和后端jsx的框架保持一致。比如一张卡片就是套三个div，最外层负责渐变色，中间层负责半透明+磨砂效果，最内层div负责展示文字。那hono中也用jsx定义好一样的结构，并在前端维护好三个style对象，调用接口把样式存起来，比如和用户id挂钩。或者把页面结构也存起来。
用户传文本过来，拿到对应的结构和样式，把文本塞进去，用Satori生成SVG，返回给用户
为了防止消耗大量资源，限流一下，比如每分钟xx次

Hono中直接使用TSX

关于Hono项目的搭建、部署，我已经写过一个简易的流程了，可以自行翻阅，这部分就跳过了。

直接在项目内新建一个目录 src/imgx

初始化该子模块下的路由 src/imgx/index.tsx并在根路由下挂载

const imgx = new Hono<{ Variables: Variables }>();

imgx.post("/gen", zvalidator('json', textGenSchema), async (c) => {
  const { text } = c.req.valid('json')

  const svg = await renderSVG(c, <><div>{text}</div></>)
  c.header('Content-Type', 'image/svg+xml');
  c.header('Content-Disposition', 'attachment; filename="imgx.svg"');
  return c.body(svg)
})

因为要直接写JSX，所以直接把文件名后缀改为.tsx即可。tsx 的内容还是按正常的写法，只不过它支持JSX了，如果用到类型的话，可以在 hono/jsx 中导出 { FC, JSX }。

结构参数用 zvalidator 校验一下，或者把此接口白名单去掉，需要登录后才能使用。

关于怎么存样式和HTML框架就不写了，随意怎么存都行，我这里直接存个json文件做演示。

当收到请求时并通过校验后，先去读取对应的样式，当然也有可能读不到

try {
    style = fs.readFileSync(path.resolve(process.cwd(), "style.json"));
  } catch(err) {
    c.set('errMsg', '不存在预设的样式文件, 请联系管理员处理')
    throw new HTTPException(400)
  }

然后把样式里的各种信息解析出来

  const { bgStyle, innerStyle, textStyle, imgSize } = JSON.parse(style)

再传给 Satori 处理就可以了

import { fonts } from '../common/fonts'

const svg = await satori(
    <div
    style={{ 
      ...bgStyle,
      ...textStyle
    }}
>   
<div style={{ ...innerStyle }}>
{ element }
</div>
    
</div> ,
    {
      width: imgSize.width,
      height: imgSize.height,
      fonts: fonts
    }

  )

因为我这个是文字生成图片，只要存在文字，Satori 就一定要显式的传入字体，也就是上边的fonts

而字体库，可以自己维护在服务器上，应该用到的也不是很多，Satori 支持 ttf 、oft 、 woff 这三种格式的字体。要把字体数据作为 ArrayBuffer 或 Buffer 传递。

我用的Bun运行Hono项目，所以可以这样处理：

import type { FontStyle, FontWeight } from "satori";
import path from 'path'
const YouSheBiaoTiHei = Bun.file(path.resolve(process.cwd(), "fonts", "YouSheBiaoTiHei-2.ttf"));
export const fonts: Array<{
  name: string;
  data: ArrayBuffer;
  weight: FontWeight;
  style: FontStyle;
}> = [
    {
      name: "YouSheBiaoTiHei",
      data: await YouSheBiaoTiHei.arrayBuffer(),
      weight: 500,
      style: 'normal'
    }
  ]

最后不要忘了处理header

c.header('Content-Type', 'image/svg+xml');
c.header('Content-Disposition', 'attachment; filename="imgx.zzao.club.svg"');

用 res.body 返回就可以了

然后可以用 hono-rate-limiter 做一下限流

import { rateLimiter } from "hono-rate-limiter";

const limiter = rateLimiter({
  windowMs: 1 * 60 * 1000, // 1分钟
  limit: 50, // Limit each IP to 50 requests per `window` (here, per 1 minutes).
  standardHeaders: "draft-6", // draft-6: `RateLimit-*` headers; draft-7: combined `RateLimit` header
  keyGenerator: (c) => c.req.url, // Method to generate custom identifiers for clients.
  // store: ... , // Redis, MemoryStore, etc. See below.
});

limiter 是一个中间价，可以直接在全局启用，也可以单独在某一个路由上使用

imgx.post("/gen", limiter, zvalidator('json', textGenSchema), async (c) => {
	...
})

当来自某个ip的请求，在1分钟内超过了50次，就会直接返回HTTP错误，提示请求了太多次（too many request ... ）

进一步处理

生成了SVG，可以用前端通过 post 请求，并设置 responseType: 'blob' ，拿到数据，然后配合a标签直接进行下载。

const a = document.createElement('a')
const dataUrl = URL.createObjectURL(response.data)
a.href = dataUrl
a.download = 'image.svg'
a.click()

但这样就和直接在前端生成图片比，看起来没有优势了。当然也可以拿到svg再用其他canvas插件处理一下，二次编辑一下。

或者直接在后端使用 Resvg 来生成PNG，Resvg是rust写的，所以速度比较快，内存占用比较小。

但最重要的是这是一个独立的接口，也就意味着我无需再打开某个卡片网站，再复制进文字，再点击下载。

我可以直接在自己的笔记软件里、在博客上、浏览器插件里接入接口，做到看到什么就分享什么，写出什么就分享什么的效果。

毕竟一个卡片网站有再多的主题，自己常用的其实就1-2个，而每次文字要分享的文字是不一样。

所以我觉得在变化的地方起手是比较舒适的操作。

不知道你意下如何？

浅谈卡片类应用的最后一步

Wed, 06 Nov 2024 00:00:00 GMT

最近一年出现了很多大同小异的文字生成卡片类的App和网站。

主要功能是可以在一个精美的页面上定制自己的内容，然后保存为图片，比如这样

看上去十分精美，也有很多种主题和样式可调，非常适合在各种社交平台发一些自己的感悟，或者在自媒体平台发一些文字类的帖子。

但不管谁去开发网站、App都不是做慈善的，大部分是奔着收费去的，做免费也得掂量掂量自己的服务器开销。所以说收费很合理，只要对用户来说好用，愿意掏钱买单就可以了。

我在简单使用后发现了几个小问题（水印问题不算），似乎可以自己优化一下。

主题很多，但常用的就1-2个

哪怕是有再多的主题和配色，用户都是为了去发表内容才会去使用，而同一个用户发内容，大概率不会一直换自己的主题和配色。

所以已经需要登录、购买会员才能去掉水印或解锁功能的App，也许可以把挑选和使用分为两个场景：初次或前期使用，可以去挑选喜欢的主题配色，去实验；在进行了某个如保存或设为常用的操作后，下次用户进来也许可以忽略掉周围包裹的各种配置参数。这样使用起来会更清爽一些。

当然，这是放在开发者的角度，要想在已有诸多竞品的情况下再切入这个赛道，也只能绞尽脑汁优化了。

以其他方式提供服务

按照我的主观想法，前面已经优化到经常使用的用户进到App里，直接编辑一下就可以导出了。

那还有什么办法可以再简化这个操作呢？

我觉得可以尝试一下不进入App就可以使用。

用户用什么主题和配色，都有记录，那其实用户只是把自己已经写好的字复制进来再下载图片，如果有办法可以随处生成图片可能体验更佳一些。

比如我在浏览器里看到某段文字，直接通过插件，右键就可以下载图片，无非是类似沉浸式翻译插件一样，去插件里登录自己的账号即可。

比如在编辑器内直接通过插件扩展，选中，右键/快捷键下载。

比如在自己的博客站，点击或选中文字，下载图片。

不过代价是以前纯前端就能导出，现在还要用到服务器资源，传输图片也是很大的流量费问题。

从纯商业的角度，一合计，可能会员费还覆盖不上服务器、流量费，那就没必要做了。

但如果是自己的一套网站，似乎有东西可搞🤔

基于 Nuxt3 + Obsidian 搭建个人博客

Wed, 06 Nov 2024 00:00:00 GMT

Nuxt是一个用Vue来编写的，可用来创建类型安全、高性能和生产级全栈 Web 应用程序和网站的全栈框架。后端是 Nitro，一个可以被单独使用的Web服务端框架。

作为一个全栈框架，不仅具备了比使用Vue开发SPA客户端更好的开发体验，还能享受服务端渲染带来的SEO优化，同时Node服务可以实现帮你实现更多的可能性。

之所以基于Nuxt从零搭建，一是为了选全栈，二是发现了nuxt/content可以读取本地的markdown文件，三是选的模板达不到想要的效果，四是过程可以作为写文章的素材。

初始化Nuxt项目

使用nuxt/content初始化项目，因为这个插件是博客的核心插件，所以初始化时直接装上就可以

npx nuxi@latest init content-app -t content

选择npm、pnpm、yarn作为包管理器后，会生成项目目录，下载依赖，我选了npm

此时直接运行 npm run dev 就可以启动项目了

启动后会有如下页面：

app.vue作为页面的入口文件，里面只有一个简单对的 NuxtPage ，作用类似于 Vue 中的 RouterView ，实际上它就是 RouterView 的包装。

同样的包装还有：NuxtLink 、NuxtImg 等等。更多 Nuxt Component

<template>
  <div>
    <NuxtPage />
  </div>
</template>

它用来显示 pages/ 下的页面

pages/ 是Nuxt生成路由的一个约定目录，其内的文件会自动生成路由。

如 pages/a.vue 会生成 /a 路由

如果想接收url参数可以这样写： /pages/a/[id].vue 或 /pages/a-[group]/[id].vue

在文件内使用这种方式来获取参数，总之 [xxx] 是它的路由规则

<script setup lang="ts">
const route = useRoute()
console.log(route.params.id, route.params.group)
</script>

如果想匹配改路径下的所有路由，可以这样写：/pages/a/[...slug].vue，此时可以再去看一下
route.params.slug 的值是什么。

查看更多关于 Nuxt Pages 👈

使用Pages不仅仅是简化了Router的配置，也是为了服务端渲染，更好的SEO。做博客的话，当然希望别人搜索某些关键字可以直接搜到自己的文章页面。而不是全部内容都在一个单页面内，由浏览器渲染。

所以自带的两个页面是怎么渲染的就清楚了。

你可以看到上面我并没有引入useRoute，但也可以在vue文件中直接使用，因为Nuxt提前做好了自动import 的配置，它自动导入组件、可组合项、辅助函数和 Vue API。

项目根目录下的 components/, composables/ , utils/ 都可以直接使用，无需手动导入。

如果你想手动导入此类API，可以使用#imports，如 import { ref, computed } from '#imports'

如果使用了第三方的包，也想支持自动导入，可以在 nuxt.config.ts 中配置。

export default defineNuxtConfig({
  imports: {
    presets: [
      {
        from: 'vue-i18n',
        imports: ['useI18n']
      }
    ]
  }
})

同时，nuxt.config.ts还可以配置 sourcemap ，全局css引入：css ，tailwindcss ，以及 nuxt/content 等等。

Nuxt的文档和Vue的类似，都非常全面，读过一遍后会对这个框架有比较清晰的了解，所以起步阶段还是建议先读文档。

NuxtContent

项目搭建好了，它默认加载了两个页面，也就是两个md文件，是/content目录下的 index.md 和 about.md 。

这不是重点，因为我也不会在这个项目目录下管理我的文章。

NuxtContent 支持配置多种文件的来源，看一下官方的配置

import { resolve } from "node:path";

export default defineNuxtConfig({
  content: {
    sources: {
      // overwrite default source AKA `content` directory
      content: {
        driver: 'fs',
        prefix: '/docs', // All contents inside this source will be prefixed with `/docs`
        base: resolve(__dirname, 'content')
      },
      // Additional sources
      fa: {
        prefix: '/fa', // All contents inside this source will be prefixed with `/fa`
        driver: 'fs',
        // ...driverOptions
        base: resolve(__dirname, 'content-fa') // Path for source directory
      },
      github: {
        prefix: '/blog', // Prefix for routes used to query contents
        driver: 'github', // Driver used to fetch contents (view unstorage documentation)
        repo: "<owner>/<repo>",
        branch: "main",
        dir: "content", // Directory where contents are located. It could be a subdirectory of the repository.
        // Imagine you have a blog inside your content folder. You can set this option to `content/blog` with the prefix option to `/blog` to avoid conflicts with local files.
      },
    }
  }
})

可以看到不仅能用content目录，还能用content-fa目录，还能用github拉取。

而目录下base配置传入的是一个文件夹路径，所以我们这里直接写上自己经常用来写文章的一个目录绝对路径就可以了。

在目录下所有文章的改动会被监听，也就是在写文章时有什么改动会实时更新在本地服务的页面上，非常方便。

我建议在一个比较高级别的目录下分出几个单独的文件夹，往博客上发的全都放在一个比如blog的目录下，其他可能不是文章的，就还是该咋写咋写。

blog下的文章，有时候也不一定都能当天写完，nuxt/content支持使用 . 和 - 作为文件的前缀时忽略此文章，不会被处理。Obsidian不支持使用.作为前缀，所以我用的-。

在blog下的文章可以随意划分文件夹，blog上不受影响，因为博客上的文章其实还是要根据tag或category用代码逻辑划分，和本地的文件夹没什么关系。

所以此时我的配置就是这样的：

content: {
	sources: {
		obsidian: {
        prefix: '/obsidian', // All contents inside this source will be prefixed with `/fa`
        driver: 'fs',
        // ...driverOptions
        base: `/xxx/xxx/notion/blog` // Path for source directory
      },
	}
}

要想正常的使用本地文件，还需要做一些改动。

之前在Obsidian写东西，文件都是中文名，而content在处理中文名时会自动忽略，我搜了下各种issue 其他语言也存在这种问题。好在content处理前后分别给了一个钩子函数，不然这博客直接夭折了

在这里写一个处理函数 /server/plugins/content.ts （没有的目录要手动新建）

// @ts-ignore
export default defineNitroPlugin((nitroApp) => {
  nitroApp.hooks.hook('content:file:beforeParse', (file: { body: string }) => {
    // 匹配markdown文件内的元信息
    const match = file.body.match(/---
([\s\S]+?)
---
([\s\S]*)/);
    if (match) {
      let frontMatter = match[1];
      const mainContent = match[2];
      // 如果不包含_path字段, 则使用title字段和一个前缀来生成_path
      if (!frontMatter.includes('_path:')) {
        // 提取 title 字段的值
        const titleMatch = frontMatter.match(/title:\s*(.+)/);
        if (titleMatch && titleMatch.length > 1) {
            const titleValue = titleMatch[1].trim();
            const pathValue = `/post/${titleValue}`;
            // 将 _path 插入到 front-matter 中
            frontMatter = `_path: ${pathValue}
` + frontMatter;
        } else {
          return;
        }
    }
    // 重新组合文件内容
    const newContent = `---
${frontMatter}
---
${mainContent}`;
    file.body = newContent;
    }
    // 如果页面内没有 _path 属性, 则自动添加为 /blog/ + 文件名
    
  });
})

在content拿到本地文件后，会编译一遍，然后放在 .nuxt 缓存，其处理后的文件内容，带有一个 _path 属性，这个属性就是页面上对应的文章的地址。

前面说中文地址会丢掉，也是这个_path出了问题，因为它默认是自己根据文件名生成的。

所以这里处理逻辑就是，处理原始内容前，给原始内容加上一个_path。当原始内容里带了_path，它就会优先用设置好的，不自动生成。

所以你如果愿意手动给自己的每个md文件都手动加上一个_path的话，也可以不用这个钩子。

以前还要注意一个问题：const pathValue = /post 这行代码，相当于写死了每篇文章的前缀是 /post 。

所以说 pages/ 下必须要有这样的结构 /pages/post/[...slug].vue 。

如果你想更改前缀，请手动同步更新这两处

这样，我们无需在项目中增加文章目录，就实现了从本地直接拉取文章文件。

用Obsidian的小伙伴，可以用Linter这个插件格式化YAML属性 ，如date、lastmod、title，这三个是自动生成而且都是必用的。tags、category 会用作分类和筛选。

那文章有了，在哪里点进去呢？

content 提供了 queryContent 来查询内容，你可以这样来查询：

const contentQuery = queryContent('post')
// 总文章数 去除了被忽略的文章
const count = await queryContent('post').count()

const contentQuery2 = queryContent('post')
// 按时间倒序以及分页后的数据
const pages await contentQuery2.sort({ date: -1 }).skip(skip).limit(pageSize.value).find()

skip limit sort 用这几个就能完成大部分操作，同时还支持 where 过滤内容，实现更多的分类查询功能。

关于queryContent的更多API👈

到这里，基于本地文件有了，也没破坏本地的写作流程，各种分类、搜索功能有了，作为一个最简博客已经五脏俱全。

后续我会继续分享我自己的博客建设过程。

最后一步就是发布到服务器

打包和部署

如果此时你没有初始化git，可以先初始化一下。

然后我要先说一个Nuxt和其他Node服务的不同点：

它打包后的文件内已经包含了node_modules ，也就是说打包后的output文件就是它的完全体，不需要再 npm install 。

而博客的文章，是本地某个目录下写的，用的别的软件如Obsidian 来管理。

这样就有三个问题：

1️⃣：打包要在本地打。因为博客文件在本地，其实也是在.nuxt内，但我们也不会把.nuxt 传到git上去。所以只能在本地打完了再传上去。

2️⃣：要修改.gitignore。这里要去掉两个一个是 node_modules 一个是 dist。

我前期因为只去了 node_modules 落下了 dist，还让我一度怀疑是Nuxt的重大bug。因为我在服务器配了gitea的action，git push上去时，需要把output整个都扔上去。

而扔上去之后因为某些node_module插件少了dist目录，会导致有些导出引用不到，我在排查pm2日志时懒得cat整个errlog，直接用的pm2 logs Blog --lines 30，恰好没发现dist丢了的问题。

然后还去github不停的搜问题，还真被我搜出一些 vite 和 nuxt 的早期bug，误以为现在还存在。于是就用重新npm install的方式暂时解决了问题。

直到我近几天才发现报错路径上有个dist，然后猛然想起 .gitignore里忽略里dist。我滴个老天爷。

3️⃣：要配个软件来写markdown。如果已经有了还好，但是可能有人用的vscode之类的东西来写md，我不确定方不方便管理 front matter。

有了以上几点，基本就是本地写文章，写完跑一下build，然后push上去就完成部署了

是不是还挺丝滑的？比项目内管理MD文件要舒服很多吧

结语

以上就是用Nuxt搭建一个可以集成本地文件的博客的最简起手流程了

其中我也是踩了不少的坑，这里分享给大家！

后续关于个人博客的建设也会一直更新，欢迎关注～～

有任何问题也欢迎私信交流

👏👏

理想的博客站

Wed, 06 Nov 2024 00:00:00 GMT

建博客就好比装修房子

一开始是毛坯房，这个阶段会改水电，留插口，留网线等等。

建博客也一样，先列好自己的大概功能，如何架构才合理且可扩展，文章怎么生成，图片往哪存，评论怎么接，服务器建在哪等等。

这些问题搞清楚了，下一步就开始刮腻子，刷大白墙。

博客也要开始技术选型，或直接选模板，只要满足自己的需求，怎么简单怎么来。

因为普通人装修肯定会考虑成本问题。

搞太多了，成本兜不住。

成本刚好兜住吧，万一再想换也心疼钱，需要犹豫再三。

所以除了必要的基本不会再拆的物件，如衣柜，先搞上。其他的能留白先留白，等着慢慢填补、捡漏。

不像富哥，先花几十万全屋定制一套，后面不喜欢什么了再换，再砸，再买。

博客也是先搞必要的功能，一下子弄太多的话，一个是没时间，再个弄乱了容易烂尾。

页面要追求简洁，看到花里胡哨的就上，阴影渐变搞一大堆，很容易审美疲劳。

更何况闲着也是闲着，产生不了其他价值，自己边摸索边学习，挺好的。

理想中的博客站

第一，以前写好的东西，不要搬家就能直接用。要不然写的文章，这里一份，那里一份，维护和修改都十分费劲。

第二，文件能很好的分类和忽略，因为要被直接搬到网站上去，有些草稿肯定是不希望去发布。分类的话还是按文件夹自己分，到了网站上其实还需要用标签等方式分一下类。

第三，文章开头必须带框架@版本。谁会希望把文章看完了才发现版本和自己用的差了十万八千里呢。要集成这个小组件，博客要支持mdx/mdc，能在md的front matter中拿到类似tags的信息（或其他方式），去展示在文章列表或文章开头，避免已过时的信息浪费时间。（我真的反感这一点很久了）

第三，带有动态模块。类似朋友圈，发一些零碎的记录和图片。

第四，带有评论模块。这个一般都有，但是要想正常使用，先注意一下自己的服务器所在地

第五，能和其他网站产生联动。这也算是我早就构思的一环了，希望自己的所有网站之间能产生一些交互，各自为战就不叫集市了。

所以针对以上几点慢慢维护，同时上线其他网站，看看能碰撞出什么😯

基于原生 DOM 实现Markdown复制样式到公众号

Sun, 03 Nov 2024 00:00:00 GMT

很多人选择了markdown语法来写文章，因为它可以在纯文字的基础上添加少量的语法，就能渲染出更美观的样式，并且可以自己扩展样式。

更重要的是它的生态十分丰富，基本上所有平台、框架都支持markdown语法，再加上开源插件的协助，可以满足绝大部分展示需求。

以前我写文章的流程是这样的：先在本地的某个写作App上把文章写完，确认没问题后，再打开某个自己还算信赖的markdown转换网站/App，一键复制内容，然后打开目标平台编辑器，粘贴进去，看看样式有没有问题，然后点击预览、发布。

直接有几次半夜写完了文章想发布的时候，markdown转换失败了，要么是代码丢了高亮，要么是有些样式错乱了。而我别无他法，只能再找另一个网站去转换，但是经常写文章的话，某些样式可能是自己自定义的，某些主题别的网站可能还没集成，非常无奈。

我一直觉得这是个问题，但碍于我也没解决，讲出来顶多是大家一起吐槽一下，所以就不了了之。

直到前一阵，我又又又开始自建博客站，这次没有找现成的模板，因为我想基于本地文件直接生成博客文章，之前搬家搬的真的累，这次要一举让我写文章这个工作流达到完美。

基于本地文件生成文章，我用nuxt/content实现了，于是问题来到「如何一键复制到公众号」上。

要实现这个功能，有几点需要明确，思路才能理顺。

复制的内容是什么

我要想保持各平台样式一致，肯定是从自己博客上复制内容+样式，然后到其他平台上。

所以，那些markdown转换的网站，他们复制的是什么内容？为什么可以带有样式？

打开以前用过的网站，写一段markdown，然后点复制。粘贴进VSCODE看看到底是啥。

如果能正常粘贴出来的话，你可能会看到如下内容（以下是我在一个mdx编辑器内粘贴出来的内容）：

而这是它的渲染结果是这样：

所以粘贴进其他编辑器的内容是什么？ html！

更准确的说是具有内联样式的html！

那为什么可能你复制完再去粘贴，可能看不到这个html内容？

这是因为navigator.clipboard 同时设置了两种类型的文本，你在支持富文本的编辑器内粘贴，就会使用html内容，你在不支持富文本的文件内粘贴，就会只保留文本。

const htmlData = new Blob([yourHTML], { type: 'text/html' })
const textData = new Blob([yourText], { type: 'text/plain' })
const clipboardItem = new ClipboardItem({ 'text/html': htmlData, 'text/plain': textData})

以上都是浏览器原生对象

然后使用navigator.clipboard写入到粘贴板：

await navigator.clipboard.write([clipboardItem])

从使用技术手段实现的角度：navigator.clipboard.write可以把带有内联样式的html代码写入到粘贴板，目标编辑器就可以粘贴出带有样式的内容。

所以问题变成了：怎么把自己的博客里的文章转换为带有内联样式的html代码

如何获取到文章的样式

获取文章样式这个操作，让任何一个前端都能写出来，但这里明显不能用简单的style属性。

因为影响样式的css，可能是内联样式，也可能是通过外部引入的css。

所以这里我用了 getComputedStyle 这个方法，传入DOM，它可以获取到DOM元素最终的样式。

什么意思？意思就是仅靠这一个方法就可能实现这个功能！

所以方案就很明确了：用getComputedStyle获取到样式，转换为style="xxx" 这样的内联样式，插入到原有的html中。

这一步转换有没有插件？有，我搜罗了几个开源项目，基本都是使用了 juice 这个插件。

它可以让你传入html，在传入css，然后帮你拼接成具有内联样式的html。所以它适合在你知道了自己的css在哪里的场景，也就是一个在线的markdown编辑器里。

我要是解决的就是脱离在线编辑器，所以肯定是不能走这个路子。

虽然getComputedStyle获取到样式有几百个至多，而又有那么多的元素，直接原封不动的拼接，内容肯定是太多太大了。

但好在用markdown写文章的人，一般追求的都是简洁、大气、低调、极客，对吧？彦祖。

所以平时用到的markdow语法，其实也是有限的几种。

而渲染后的文章，通常也只有这几个元素：p、a、span、blockquote、strong、code等。

它们分别对应了：段落、超链接、代码块、标注、加粗等。

所以只需要把影响样式的样式属性限制一下，从getComputedStyle里只取这几个！

通过调试得到样式的全部覆盖

先思考一下那些样式影响了文章的样式，列出来：

// 对元素有影响的属性
export const EffectCssAttrs = [
  // 'fontFamily',
  'fontSize',
  'fontWeight',
  'color',
  'textAlign',
  'lineHeight',
  'whiteSpace',
  'textSizeAdjust',
  'overflowX',
  'padding',
  'paddingTop',
  'paddingBottom',
  'paddingLeft',
  'paddingRight',
  ...
]

然后在通过 getComputedStyle 获取到dom的全部样式时，使用此列表过滤：

	const computedCssStyles = getComputedStyle(childDom, null)
    // console.log(`computedCssStyles`, computedCssStyles)
    const _effectCssAttrs = pointCssAttrs.length > 0 ? pointCssAttrs : EffectCssAttrs
    _effectCssAttrs.forEach( cssAttr => {
          const value = computedCssStyles[cssAttr]
          if (value) {
            curCssStyles[cssAttr] = value
          }
        })

这样，我们只需要拿到文章最外层的Dom，循环所有子元素，获取到其有效样式，组合成内联样式

然后再把全部Dom整合起来，就得到了一个带有样式的html字符串。

然后再衔接上一小节的navigator.clipboard Api，就已经实现了功能。

但是测试下来，还是有很多需要填补和优化的地方。

比如影响样式的属性列举的不太全，导致有些渲染的不对劲；

比如fontFamily这个明显不需要每个元素都获取一遍的样式需要单独处理；

比如文章太长时，元素太多，复制出来的内容太大，也许精简一下也能得到相同的效果；

比如代码块 pre 元素内，每个span其实只需要color；

比如博客自定义了图片组件用于放大查看，其他展示平台只需要img单个标签等等类似的问题。

比如在A平台有效，在B平台有些样式不支持，需要单独处理。

这些问题列出来看着有点多，但基本都是先把主要功能打通后，逐个解决的，问题不大。

最后再来理一遍思路：

拿到文章最外层的元素，循环处理
封装一个整合单个元素的递归函数（getDomCssStyle)，放在循环内，获取到处理后的带有内联样式的html字符串
- 处理各种特殊情况：无dom、忽略某些nodeType、忽略某些无用的标签（tagName）、忽略某些无用的class（classList）
- 特殊处理某些组件，如图片 img
- 设置缓存，优化代码。（针对文章又长又复杂时）
- 深度优先，有子元素时，先去递归组装好全部子元素
- 组装最终的dom字符串，return
- 优化：抽离函数、常量等
使用 ClipboardItem （两种类型 text/plain 、text/html ）创建实例
使用 navigator.clipboard.write 实例
粘贴进其他编辑器

以上全部语法均基于原生DOM、浏览器原生对象。

结语

以上就是我为了脱离第三方markdown编辑网站而做出的一个小小功能，没有依赖任何第三方插件，目前已经应用在了我的博客站上，用来往公众号同步。但我的博客站还没搞完，所以先不贴出来了。

功能比较简单，相信大部分人都能实现，但我就是没搜到有类似的插件。大家都是画地为牢，做了一个个功能完全一样的markdown编辑网站...

幸好我解决了这个问题，再也不用发愁啦！

对自建博客或是此插件感兴趣，欢迎关注～

基于本地文件搭建个人博客站：无缝配合Obsidian

Fri, 01 Nov 2024 00:00:00 GMT

搞博客站一直有些痛点：文件不停的搬家、需要多处同步修改、无法复制到其他平台、界面同质化严重。

在别人的框架里，很难实现所有的个性化需求，所以我想试试能不能通过自建来达到一个近似完美的状态。

先有文章再有博客

写文章可以说是一个表达、展现、锻炼自己的优秀方式。

因为我觉得大部分人并不是不爱交流，或者天生内向，只是没有碰到和他有共同话题、共同爱好、共同价值观的人。

再加上工作画地为牢，家庭一地鸡毛。话多了是不专业，是矫情，也容易“祸从口出”。

所以用文章记录是一个既不打扰别人，又满足自己的一种方式，写好了还能从中获利。如果有写作的冲动，何乐而不为呢?

PS: 从文章到博客的使用场景有点类似学英语。其对诸如程序员等人群来说有很大帮助，但仅
用于看和写上，我实在想不出普通打工仔的听和说的场景在哪里，但现在更多的App是让用户去
听、说、记，也许会有所帮助，但我总觉得相较普通人来说不是最好的方式。

有了文章就要发出去给别人看，因为发出去不仅仅是表达自己的观点或发泄，也是和别人的观点产生碰撞从而修正自己的某些错误。待在本地笔记本里只能没事拿出来emo一下。

大部分人发文章都追求的是简便，比如直接发在微信公众号等自媒体平台。自建的话用类似WordPress、Hexo、Halo、Hugo、Typecho等现成的框架。

不管在哪里写，我通常都不会直接在发文的平台下直接写。一般会先在本地写个草稿或大纲，在一天或者几天内把它写完。因为写的可能比较零碎，后续也得自己整合。

写完后如果要发到多个平台，我希望他们在各家的App上打开时，尽量在样式保持一致，这非常合理，但也有一些门槛：在本地记录的格式要兼容各家平台。（没样式相当于自嗨，把平台当成自己的日记本）

所以从我的角度来讲，markdown是不二之选。但有的平台他就是不支持markdown，支持markown的也可能不让你自己修改样式。所以文章保持全平台一致是解决不了的，只能保持部分平台一致（转为富文本）。

另外文章的内容是受平台方监管的，比如你在A平台的文章里不能出现B平台的联系方式、要控制自己不能发一些不该发的言论等等。

你的文章推荐机制也是由各平台自己决定，比如公众号的文章你在搜索平台上搜不到的，只能微信内部搜。一些社区或平台要看你文章打开率、点赞率、评论数等指标来决定是不是要给你推流等等。

没办法，谁让用户在他们手里呢。

当你感觉到膈应了，又看到别人精美的博客时，很容易产生自己建站的冲动。

前期其实可以0成本选择一些现成的平台去发文，如果满足不了自己，再去研究自建。

博客框架的「框架」

自建博客有很多框架可选：WordPress、Hexo、Halo、Hugo、Typecho、Astro、Next、开源仓库等等。

但他们都有自己的框架。以下痛点也来自于我不接受这些“框架”。

框架本身有自己组织文章文件的方式，一般是让你放在某个（/content）目录下自行编译或是提供你一套编辑器和后台管理系统，然后通过一个或多个配置文件进行站点内容的自定义，再通过开源插件或付费插件实现更换主题的功能。

但是前面提到了，我本身有固定的App（Obsidian）去写文章，要想把文章生成站点，还要再复制到框架项目的指定文件夹下。如果已经发布的文章更新了、删除了，同步过去是个问题。每次写完了还要再塞过去也是个问题。并且框架对于文章内容和头部元信息的处理方式还可能和自己平时的习惯相冲突。

再来说主题的问题。

好框架大家都是追着用的，所以有大批的人在用相同的框架。

那好看的主题也有相当一部分人都会觉得好看，所以你会发现很多主题虽然好看，但是用的人太多了，打开每个都一样。另外用的人里有一大部分不具备修改或自定义的能力，缺少了很多个性化。

更不要说你可能会换框架... 这个用腻了，再来个博客搬家，于是上面的操作又来了一遍。

看到这你也发现了，所有的问题都来自于自己喜欢折腾，人家嫌麻烦的直接发朋友圈都没觉得有啥问题。

不过也没关系，喜欢折腾的人总会吸引到其他喜欢折腾的人，咱们继续往下折腾！

自建博客

在说自建前，补充一点：

上面的痛点，其实能提供云服务的笔记App（类Notion）已经解决了。

他们有一致的风格：你换啥皮肤啊，大家都一样。

能直接生成网站或分享链接：在平台上写，平台帮你生成，无需自己操心，顶多付个会员费。

支持导出多种格式：你想再发到什么平台，自己再导出然后转换格式。支持到了多平台发布以及本地化备份的需求。

那你猜我为啥用Obsidian？

就是不想用别人的云，不想把数据都放在别人服务器上！

最近两年阿里云等云服务商的故障热搜大家也有所耳闻。

一旦云服务商挂了、网络不好，你的笔记看也看不见，写也没法写，刚写完的也可能没保存上。

我自建的挂了，我不会骂自己。但是我花钱买你的App却用不了，甭管谁的问题都得骂。

再说我的笔记都在本地，自建的只是个展示平台，数据安稳的很。Github这类平台可以作为同步和备份使用。

也正是因为我的笔记是本地的markdown文件，所以框架必须得支持我拿本地的数据进行编译，再部署到服务器上。能直接做到这一点的好像真的不多，我目前发现了nuxt/content 可以做到这一点（有用过其他的希望能在评论区补充一下😘），所以我开启了一个基于Nuxt从零搭建博客的计划。

首先本地文件还是用以前的方式写，不需要搬家，只需要把本地的文件整理好，然后开放给框架一个读取的目录即可，因为可以直接读取后本地编译。备份方式还是用自己习惯的方式，没有侵入性。元信息还是用Obsidian的Linter插件维护。

其次页面样式靠自己的“阅历”，多看优秀的博客设计或是界面动效，组合到自己的博客上，「撞站」大概率不会。

往其他平台如公众号发布的时候，我希望是直接在自己的站点上集成这个功能，写完文章，博客站本地编译好自动部署，我直接点击按钮能把html内容复制出来最好。这样能保证文章的样式是一致的。

现在的流程是把markdown内容复制到另一个工具网站里，然后再复制生成好的html内容，粘贴到公众号编辑器内。像是掘金的话，直接把markdown源码复制过去，他是支持md编辑器的。其他平台也要么是支持md，要么支持富文本。

这个功能还在思考中，因为虽然nuxt/content负责渲染markdown，但是没法直接拿到具有内联样式的html内容，实际内容是元素带有className，再通过css渲染样式。而像md转公众号的工具站点核心是把编辑器内渲染的html和固定的css通过juice(插件)渲染为一段内联样式的html内容，然后再把剪贴板的类型设置为text/html，粘贴到公众号编辑器中时就会带着样式了。

在解决掉这个问题后，我的本地写作流程是这样的：

打开obsidian开始写东西，写完后，去博客项目目录下运行一行命令npm run build，博客会通过gitea action自动部署上去，如果要发布到其他平台，打开博客站域名找到文章，点击复制，再去对应平台粘贴。

感觉挺带劲儿的，几乎只剩下了「写」这一件事。

结语

这个基于Nuxt从零开发的博客，我会全程记录文章然后分享出来。

目前进度可能有30%？评论、搜索、分类、类朋友圈等功能都是自己开发或集成，速度可能不会特别快（少量涉及后端HonoJS）。

后续代码也会开源，有兴趣的可以自己去搭建。

如果你有相同方向的需求，不管有没有开发能力，都可以在评论区/私信留一下言，满20人的话我拉个小群，方便随时更新进度，或收集一些需求，后续提前开放源码或帮助大家也建起站来。

以上就是关于我的「理想博客站」的全部内容啦~

👋🏻👋🏻

程序员探索副业一年了，收益有多少

Wed, 30 Oct 2024 00:00:00 GMT

从23年的11月份左右，我开始尝试在主业外寻找其他能获取收益的方式（以下统称为副业），到目前为止有一年了，所以这篇文章简单总结一些小感悟。

之所以是感悟，是因为没有通过副业获取到利润，虽然也没有赔。所以喜欢直接看数字来刺激自
己的可以划走了

社群的好坏

刚开始是接触副业时，我其实知之甚少，当时脑子里只有模糊的一种想法：就是用写代码的任何方式赚到钱。

这是一个思维惯性，也一直持续到了现在。

我没有全盘否定它，因为我觉得只有写代码算是符合我的所谓的技术杠杆：即通过技术来获取远大于付出成本的收获。

但也不可否认，如果只是做类似外包一样的工作，其实就是劳动力杠杆，甚至没有杠杆，纯纯打工。

纯纯打工那啥时候是个头儿呢，我也是抱着这样的想法，以及在外力的环境的压迫下开始在各种社交平台、社区来寻找一些「社群」。

这种社群有一个好处：会拓展眼界。

说白了，就是我以前只知道给公司干活，拿工资，和同事间交流、扯皮、撕逼，对于项目是怎么谈成的，怎么推广的，推广给谁了，费用是怎么定价的，钱又被谁分走了多少，甚至我自己应该怎么多拿一部分钱都几乎没有自己的认知。（只要眼界/认知够低，总会得到拓展）

而加入一个社群，不管他发的「日入xxxx元，我是怎么做到的」的文章/项目真实性如何，其中必有我未曾了解过的领域。所以我也是抱着试一试的心态去尝试每个小项目，去了解一下：从撮合一个项目，到推广、引流，以及抽成等方方面面的经验。

但是，对于一些小的好上手的项目，基本都是只参与引流这一步，然后拿一笔提前讲好的抽成。大概100人的群里，有5个人左右，会在短期获取到看似比较客观的收入（因为后续的收入我无法印证）。这个比例在每个引流相关的项目里都差不多。但讲真的，这和被公司雇佣其实没有区别，大家可能也是现在私活越来越少，被迫尝试各种领域的收入吧。

有好处就一定有坏处，对吧。

坏处就是：前期你不容易察觉到这个社群的调性，而这个调性可能会导致你偏离初心。

意思就是，你从完全不了解，到新加入一个以搞钱为目的的社群，很快就会被各种信息狂轰乱炸，然后一边觉得很有用说的很对，一边又疲于尝试，然后没好结果就用没执行力来PUA自己。

从你的角度是进入了一个副业圈子，努力寻找能搞钱的项目，积极参与，每天多挣一点。在社群圈子的或者圈子里拥有定价权的人来说，任何来的人都是要被淘洗一遍，最后选出的你也许不过是个好用的劳动力。真正有价值的人，会被吸收为人合伙人/投资人。当然，占比最高的还是毫无进展的人。

所以，大量尝试是必须的，但其中的影响可能要等到你尝试后才能发觉。

所有的尝试不过是从旋涡的中心努力的往更外围移动。你在动，别人也在动，旋涡自己也在动。

时间、精力、正反馈

和大部分打工仔一样

在公司活多的时候，我会嫌弃公司没有给自己提升技术的时间

在公司活少的时候，我会责怪公司没有给自己提升技术的场景

从活多变为活少，我会珍惜这来之不易的时间，狠狠的玩上一阵子游戏

从活少变为活多，我会怀念以前那活少的日子，并告诫自己有时间了一定要好好学点东西

于是在这种反反复复的节奏中又度过了一年...

不过我很高兴，在过去的两年里，这种情况正在逐渐变好，具体表现为：报复性休息和玩乐的次数和时间变少，吸收和产出的东西在变多。

其实很早就知道，做事要有执行力，做事要少想多做等等类似的理论，而且我也非常认同。

但是这个问题就是，放在自己身上是真不好使。

现阶段的原因有很多

比如平时就是很懒，有人劝我学，有人劝我躺，我本能的选择了舒适的一方。

比如杂事缠身：被领导批了，绩效低了，工作累了，孩子病了，老婆怒了，心情差了，代码出BUG卡住了，出新游戏了，游戏出新DLC了，旧游戏又回归了，股票涨了，股票跌了... 等等

你可能觉得我在扯蛋，但这是真事！这个问题只能靠自己「悟」，别无他法

平时的时间很有限，但不管是从哪里获得的、什么时间点，我现在只遵循一个原则：就是不停的执行自己的计划。

计划只适用于自己，所以我也没法推荐，但我可以讲个大概

我的计划包含输入和输出两部分

输入指的是知识的获取，包括：

多看别人的源码、架构。精进技术，逐渐连通一切
多看有设计感的作品、已经有用户量的作品。提升自己的审美，思考对需求本身的认知。
多看书、视频。财富、家庭、教育、交流相关的书籍和视频，能看则看

我的出发点永远是精进自己的技能，因为我要靠这个赚钱，虽然并不是只能靠这个，但是肯定没理由放弃自己最擅长的部分。

其他知识的获取，主要是为了增加自己的厚度，看的远了，眼前的鸡毛蒜皮就不算什么了。其次，我要首先理解世界，才能告诉下一代我的理解。

输出和输入相关联，指的是要对应做出的改变：

做出自己的产品。无关市场、用户量，更多的是技术的实践、落地
写作技能和记录产品。产品做的够多，网上这么多人，必然存在类似的需求，要想让别人看到，要靠自己多发声，所以我要不停的写文章和发帖表述自己在做什么。同时多写也能锻炼写作能力，这是一项值钱的基本能力。
生活的规划。把自己家里收拾好，才是踏踏实实干技术的最大的底气。甭管是租的还是买的房子，有没有结婚生子。保持家里整洁、美观、个性化，氛围上积极、乐观、松弛，永远都没有错。努力挣钱最后不还是体现在生活上吗? 万一一夜暴富了，咱这气质没跟上怎么办，所以生活平时就注重起来！

总结：抓住尽量多可用时间，去执行自己的计划

当然不可能利用好一切时间，只要能达到一个相对满意的程度就可以了。

关于精力，我只能说：早睡早起，锻炼身体！

关于正反馈，我指的是产出被别人看到，受到鼓舞，从而推动自己进行更多输入到输出的转换。而不是那种企图获取自己家人的鼓励的正反馈，因为这件事在一个无法提供丝毫情绪价值的典型中式家庭里显得十分愚蠢。我对此无限悲观。

用充足的精力维持输入和输出，同时输出带来的正反馈，再持续强化这一过程。

这算是我近一年的最大感受了。但是请注意，这些放在整个生活里仍然是一小部分。

目前的打算

经过一年的摸索，现在我可以比较确定，我会把主要精力放在技术和技术相关的产出上。

其他的副业，有机会就尝试，没有就算了，还没到刀架脖子上的程度。

产出主要是文章和App。

App可以是网页、客户端、插件、脚本，这些都算，但我会先以串联自己的工作流为目标，先让这个「集市」有个样子，而不是空想一些无法落地的功能，这样也能使我不至于一天啥也没干出来。

文章则主要是学习技术和做App的伴生品，我会记录开发教程、灵感、经验、踩坑等等。可能还会有一些关于日常生活的主观分享、旅行记录等等。载体的话，一是发在各平台，比如公众号：「早早集市」，二是自建平台，比如博客、工具站、客户端工具。

至于有没有用，我真的没法告诉你，因为这不是一条能够被快速验证的路，只能看自己是否乐在其中。

最后，来回答一下标题，收益有多少？对于金钱来说，是负的🥲。

但对于前进方向和自身的把控上来讲，清晰了很多，已经很知足了。

2024年，想入坑前端or后端开发需要学多少才算够用？

Mon, 19 Aug 2024 00:00:00 GMT

你是否好奇，如果要在前端或后端领域深耕，需要具备哪些技术要点才算足够?

Github上有一个开源项目 developer-roadmap，提供了一份完整的技术路线规划。在这里和大家分享一下

前端开发路线

![[1-img-20241119141198.png]]
国内其实用Vue偏多，但国外是React , 生态也各不相同

后端开发路线

实际上我在网站上看到的，后端比较推荐JavaScript 和 Go，但下载下来的pdf没有提供他的Personal Recommendation / Opinion 🤔。

![[1-img-20241119141173.png]]

相信这个对很多想跨入另一个领域，但不知道什么才是这个领域常见的技术路线的开发者朋友来说，会一些帮助和启发。

如果你对其他领域，如Android、AI、大数据、游戏开发等等，也感兴趣，可以自行访问：

https://roadmap.sh/

结语

国内国外的技术环境不能一概而论。

足够与否完全取决于你所在的或长期居住的城市中对互联网技术的包容度。

但这不妨碍我们自由探索真正开放、包容、有深度的技术知识。

希望对你有所帮助和启发，👋🏻👋🏻👋🏻

【contentlayer】兼容不同的md文件metadata的字段

Sun, 18 Aug 2024 00:00:00 GMT

markdown顶部可以设置一组元数据，用于解析成作者，发布日期，简介等信息

使用过多种Markdown编辑器以及多种博客框架的人都知道，每个框架使用的字段有可能不太一样。

比如简介。有的用的是description，有的用的是summary。

如果你在一款md编辑器中写好了一篇文章，这篇文章被你使用Astro的某模板进行开发和部署，后面你又换了其他的框架，比如NextJS，结果新框架使用的matedata是不一样的，而你又有那么多的文章需要搬运。这无疑是一件很头疼的事。

虽然作为一个程序员，可以自己写一个脚本，批量的把matadata修改一下，再放在某一个文件夹内，但这就明显会造成一种心智负担：很快你就会混淆，一篇文章的简介到底该写desc，还是description，还是summary。

所以，我希望可以是不关心文章的简介用什么字段表示，只管写文章就好了。

于是乎，我就调研了一下contentlayer的文档，把自己手头的模板稍稍改动一下，用来支持多种字段表示同一个信息

我目前在用的NextJS博客模板是Tailwind Nextjs Starter Blog，所以我以这个为例

在contentlayer.config.ts中，有一个computedFields的配置

假如我有些文章发布时期用的 date，有些用的 published，那就可以这样配置

const computedFields: ComputedFields = {
    // ...
    showDate: {
        type: 'date',
        resolve: (doc) => doc.date || doc.published,
    }
}

同时，在Fileds里加入这两种字段

export const Blog = defineDocumentType(() => ({
    name: 'Blog',
    filePathPattern: 'blog/**/*.mdx',
    contentType: 'mdx',
    fields: {
        title: { type: 'string', required: true },
        date: { type: 'date', required: true },
        published: { type: 'date', required: false },
        // ...
    },
    computedFields: {
        // ...
    },
}))

然后再去修改date的文件里，可以边看页面边调试

把相应的 post.date 改为 post.showDate
把 const { date } = post 改为 const { showDate } = post
然后再把date插入的内容处，替换为showDate即可

确保替换完上述内容之后，你就可以随意在其他md编辑器中使用你设置好的多种字段了

有任何问题，欢迎咨询。

👋🏻👋🏻

Memos Apis

Thu, 15 Aug 2024 00:00:00 GMT

注意：Memos版本为： V0.22.4

GET: /api/v1/memos?filter=

Spelling the string directly may not succeed. I suggest requesting in the following way.

const filterValue = "creator=='users/1'&&tag_search==['Blog']&&visibilities==['PUBLIC', 'PROTECTED']&&limit==30";
const encodedFilterValue = encodeURIComponent(filterValue);
const url = `https://example.com/api/v1/memos?filter=${encodedFilterValue}`;

it's all about query params ↓

var MemoFilterCELAttributes = []cel.EnvOption{
	cel.Variable("content_search", cel.ListType(cel.StringType)),
	cel.Variable("visibilities", cel.ListType(cel.StringType)),
	cel.Variable("tag_search", cel.ListType(cel.StringType)),
	cel.Variable("order_by_pinned", cel.BoolType),
	cel.Variable("display_time_before", cel.IntType),
	cel.Variable("display_time_after", cel.IntType),
	cel.Variable("creator", cel.StringType),
	cel.Variable("uid", cel.StringType),
	cel.Variable("row_status", cel.StringType),
	cel.Variable("random", cel.BoolType),
	cel.Variable("limit", cel.IntType),
	cel.Variable("include_comments", cel.BoolType),
	cel.Variable("has_link", cel.BoolType),
	cel.Variable("has_task_list", cel.BoolType),
	cel.Variable("has_code", cel.BoolType),
	cel.Variable("has_incomplete_tasks", cel.BoolType),
}

Next x Memos 懒人建站

Tue, 13 Aug 2024 00:00:00 GMT

我觉得博客站里的内容主要有两种展现形态。

一种是文章，有头有尾，长篇大论，输出观点，阐述事实。

一种是动态，即兴发挥，图文为主，类似朋友圈动态，碎片化。

文章好说，所有框架都能满足，无非就是把文章文件（markdown）放在项目里，然后编译出来，再部署。

把动态加入进去，也许用Memos（指和Memos类似的开源作品）作为数据来源是个不错的选择。

那既然能做博客上的动态页，是不是也能给其他站点作为数据源呢

起初我想选一个框架

都说前端卷，天天造轮子，天天撕逼，堪比娱乐圈。

我学的速度还没框架更新速度快。

那卷之后有什么好处呢？

我觉得最大的好处就是有工具、插件、模板等大量的半成品可供我们选择。

然而最大的坏处就是：太大量。

所以说真别乱喷人家造轮子的。造完了，好用，咱不也得用吗？

2024年了，能建博客站点的框架实在是太多。每个框架的模版又非常多。

要是真挨个挑选下来，我估计我这文章也不用写了，时间全浪费在选择上了。

所以我也不推荐什么框架了，萝卜青菜各有所爱，选了之后还是要写文章才有意义。

但是呢，这个非常繁琐的选择过程，让我产生了一个想法。

然后想做一个选框架的导航站

刚才说到，前端框架卷的狠，产出多。

所以现在就有了一个问题：只了解了Vue、React、Node，这不足以让我直接做出东西来。

就必须还得有个开发模板，有人帮我用Webpack、Vite 搭建好了项目，再帮我配置好一些基本的功能，像什么前端的router、store、Tailwindcss，Node的middleware、orm、jwt 等等。

配好了还只是第一步，Node版本合不适合，框架版本新不新，数据库用的啥等等类似问题还有很多。

所以，我去哪里找这些合适的模板呢？

没有的话要不我搞一个导航站？

==我寻思着肯定已经有人做过这种类似的导航站了，但是确实没推广到我脸上来。==

所以，我在准备开始这个导航站前，还是先捋了捋功能点（前端页面），捋了捋需要哪些接口（后端接口），怎么管理这些数据（管理系统）。

但是捋完之后，肉眼可见的，开发成本太高了。

还没怎么开始我就不想做了。

于是我开始做减法，前端页面尽量简洁，后端功能尽量简单，管理系统够用就行。

然后你懂得，开始之后总会有各种各样的阻碍卡住。

所以我觉得还是要再做减法。

用偷懒的方式实现

我用我当前的认知继续思考。

我做一个后端服务，是为了给我的前端页面提供接口以及保存和获取数据。

至于数据怎么存，表结构合不合理其实无所谓。

甚至数据安不安全也不重要，我写出来就是给别人看的，没有私密信息。

我能不能找个现成的后端服务为我提供数据录入和数据获取接口，我只需要写写前端代码，调调接口就行了呢。

所以说 Memos 貌似能满足我的要求。

Memos是我用docker直接部署到云服务器上的，现成的开源项目，我不用写代码。

也提供了一个前端界面，可以录入文本，可以发图片，可以生成可管理的Access Tokens用于接口请求。

这就相当于，我在Memos写东西，就是在给前端提供数据，只要前端通过接口拿到一条Memo后，能根据某种规则解析出内容即可。

我在Memos打个导航的Tag开始发上几条Memo，然后前端获取导航相关Tag的Memos，再把内容以另一种形式呈现出来。这不就是我想要的效果么？

甚至我在Memos再发点有关其他品类的Memo，比如植物，那前端再换一种方式展示出来，这不又是一个养花养草的科普站点？

果然，前端页面也是个换皮的游戏。

一套数据，换个皮，换个交互，就是另一个App了。

最终姿势

博客用NextJS的模板搭建。模板是tailwind-nextjs-starter-blog。

博客的文章部分，还是用传统的方式，把md文件放在项目中，然后build，docker部署

动态部分，自己新开一个页面，用Fetch去请求自己Memos服务的接口，筛选出想要展示的Memo。

导航站（如果还做的话），也是用Memos录入，打上指定Tag和权限，在前端获取后，写好一套解析规则，比如Markdown的里一级标题就是title字段，内容标签也区分开来等等。

这样，Memos就是我的数据录入平台+接口服务+后台管理系统，不需要开发，0成本。

Memos的使用方面。

在电脑端，用Memos的前端页面进行记录。

在手机端，我喜欢在微信里打开H5页面，然后把页面添加到浮窗里。感觉要比使用Memos的App或者小程序要舒服很多。（不过要用https，不然时间长了可能会禁止访问）

最后，要生产其他展示类的站点，就可以直接使用Memos里的数据，先把网站做出来，后续觉得有搞头的话，再把必要的后端服务具体实现出来。没人访问的话，只建一个前端也花不了几天，成本比较小了。

然后涉及到数据，记得时常备份，被人攻击就重启+恢复备份。

或者再给Memos限制一下只接受来自 47.xx.xx.xx 等ip的请求，也可以避免一下被人操作Memos，因为Memos的Api是公开的，别人很容易就知道你创建和删除Memos的接口。

或者，在本地把Memos请求下来保存到文件里，直接把页面用Next编译成静态网站再发布，对于数据更新不太频繁的网站也是可以的。

或者，自己在服务器加一层中间层，请求方式改为请求中间层，这样别人就不知道你创建和删除接口是怎么调用的了。

当然，如果定时备份的话，自己再恢复也可以的。

后续优化

做好基本的基建工作后，后续优化我觉得就是把记录这件事再简化，做到随手可记。

作为手动码字录入，Memos已经是挺方便了，我打开微信就能记录。

进一步增加录入方式，大概是再加个浏览器插件，在网上冲浪的时候，看到想要记录的内容，选中后弹出个表单，简单填写后，直接通过Memos的接口录入进去。

文章的话，也是需要一个脚本，在本地写完后，一键发送到博客项目的文章目录下，再触发一下部署动作。

当然这一切对于非开发者来说，可能最大的问题是：没有现成的好用的工具。

能做出来给你用的，不一定好用，但一定收费。

而为爱发电的，虽然不收费，估计也受众也小，也懒得大力推广。

ok，这就是全部内容啦。

不知道对你有没有帮助呢？

欢迎一起来讨论~

Memos自建服务入门指南

Thu, 25 Jul 2024 00:00:00 GMT

Memos是一个开源免费的私人版/家庭版推特。适合可以在私人服务器、家庭Nas上自建服务，适合喜欢折腾的小伙伴。

本文内容主要有三部分：

1、从原作者仓库拉取Memos代码，并本地运行项目

2、通过docker发布自己的版本到docker hub 和 云服务器容器服务

3、在自己的服务器上运行和更新Memos

选择合适版本

首先选择一个版本，克隆到自己本地，或者直接fork到自己的github仓库再拉下来。

因为每个版本的功能不太一致，可以先用 docker desktop 跑一下各个版本，本地看看效果，了解一下哪个版本比较好用。

也可以在本地用 docker build命令运行当前拉下来的版本，再去docker desktop跑起来

注意有几个参数，我在图里做了标识。

我这里使用的是0.22.3版本，早期版本我没接触过，所以直接用的最新版，看了下界面和功能完全够我使用了。

注意选择后，咱们的版本就固定了，大概率不再跟随原作者更新，除非有非常好用的功能，再进行手动合并

代码到本地后，首先要保证自己有运行环境。

不懂Node或Go如何安装，直接问AI就可以了，现在AI的辅助能力其实要比大部分半吊子开发者要强得多。

AI 我用的豆包。

安装依赖和运行项目

首先是Go，根目录下就有go.mod，里面是项目的依赖。不懂就直接问AI，可以解决80%的问题

go mod tidy

然后是web，注意要 cd ./web，他这里用的react，不过框架对于老前端来说影响不大，基本都能很快上手

pnpm i

如果只是想看一下界面，可以先用docker跑起来

打包

docker build ./ -t memoz --load

打包后就可以在你的 docker desktop 里看到镜像了，直接点击运行即可，也可以用命令运行

docker run -d --name memoz -p 5230:5230 -v /memos/:/var/opt/memos memoz

注意 memoz是我起的名字， /memos 是我的挂载目录，最后的memoz是我刚才打包好的镜像。这些要视情况更改。

运行成功就可以打开 http://localhost:5230 看到界面了。

如果想要本地边开发边调试，可以分别运行go和web

停掉docker运行的容器后，在项目根目录下先运行go服务

go run bin/memos/main.go

然后 cd ./web 到前端目录下

pnpm dev

然后前端项目就会运行在 http://localhost:3001 ，此时再从浏览器访问就可以了。

发布到docker hub

memos推荐我们直接用作者发布好的包进行部署，像是这样：

docker run -d --name memoz -p 5230:5230 -v ~/memos/:/var/opt/memos usememos/memos:latest

那如果我们想拉取自己的版本，就要像作者一样把自己的版本发布上去

首先你要注册好自己的账号（docker hub）

然后要在本地登录

docker login

然后给刚才build的镜像打上标签，不写具体tag，默认就是latest

docker tag <image_name> <dockerhub_username>/<repository_name>:<tag>

然后给打好标签的镜像推送上去

docker push <dockerhub_username>/<repository_name>:<tag>

登录到docker hub网站上，就可以看到自己发布的镜像了。

然后在服务器上把自己发布的包跑起来就行了

docker run -d --name memoz -p 5230:5230 -v ~/memos/:/var/opt/memos <dockerhub_username>/<repository_name>:<tag>

然后你就会发现，根本拉不下来，哪怕是配置了代理，也没法顺利拉取

所以我们还是要把自己的镜像发布到对应的云服务器厂商自己的容器服务上，由于我的服务器是阿里云，所以此处我用阿里云演示

发布到阿里云容器服务

发布过程和docker hub是一样的，只不过登录的是阿里云容器服务的账号密码，推送的目标也是阿里云的容器服务

打包

打包的时候也有一个坑，就是要注意服务器的platform，在本地打包和push前就要加上参数。比如我这里是linux/amd64，你可以先不管，等在服务器上运行时，会提示你报错信息，然后再根据提示加上platform参数重新打包发布也可以。

docker buildx build ./ -t memoz --load --platform linux/amd64 (对应阿里云ubuntu服务器)

打Tag

打标签前，需要在阿里云控制台里，先创建好自己的命名空间，我这里是zzstudio0

docker tag memoz registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

发布

docker push --platform linux/amd64 registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

此时本地操作已经完成，登录到云服务器再去拉取和运行发布好的镜像

运行和更新

拉取

拉取前也是得登录，参考上边

docker pull --platform linux/amd64 registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:latest

运行

运行的镜像名称可以通过 docker images 查看，也就是 registry.cn-beijing.aliyuncs.com/zzstudi0/memoz 部分换成你自己的

docker run -d --name memoz -p 5230:5230 -v /home/memoz/:/var/opt/memos registry.cn-beijing.aliyuncs.com/zzstudi0/memoz

运行后通过 docker ps，可以看到正在运行在5230端口下，如果想直接通过5230端口访问，只要在阿里云控制台-云服务器-安全组中打开端口即可

当自己在本地新增或者修改了某些功能后，再按照上述的步骤，重新发布一个新版本的镜像

然后在更新和重新运行镜像

更新

container_id 可以通过 docker ps 查看到

停止目前运行的容器
docker stop container_id
删除容器（为了避免名称冲突）
docker rm container_id

然后拉取新推送的版本，比如1.1.0

docker pull --platform linux/amd64 registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:1.1.0

然后再重新运行新版本

docker run -d --name memoz -p 5230:5230 -v /home/memoz/:/var/opt/memos registry.cn-beijing.aliyuncs.com/zzstudi0/memoz:1.1.0

再从外网访问，检查页面是否有所变化

总结

本文介绍了如何本地运行Memos，以及如何发布和部署在自己的云服务器上。

因为Web部分只是普通的React+Vite，对大部分人没什么难度，所以后面修改细节就不水文了，功能方面的改造会水一水。

说到底，这只是一个普通的内容工具，关键还是真的有内容要发布才行。

文章发布时，作者已经更新了0.22.4版本，修改了标签和分类的筛选机制（0.22.3版本比较难用），把热力图也挪到了首页，所以推荐新入坑的小伙伴直接上最新的版本。

以上就是全部内容啦👏

对Memos感兴趣的话欢迎私聊讨论~

本地版微博?开源版Flomo？服务器自建Memos有什么好处

Thu, 11 Jul 2024 00:00:00 GMT

一般写博客，都是长篇文章，类似我现在这篇，是一个有头有尾有内容的长文。

但是如果是灵光乍现，或是一时的牢骚，或是转瞬即逝的感慨，这种片段内容你们会发在哪里呢？

朋友圈肯定是个首要的选择，微博好像也可以，小红书也不错。但是你发的内容如果更加私人化，不想被别人看到，或是你无数灵感中的一个，后续还要整合起来，这种公共平台可不会支持你导入导出。

app图标图

所以很自然的就会诞生一些针对短文的卡片笔记App，比如Flomo。非常适合随手记录，可以和你的微信进行联动，并且有热力图，可以设置标签分类。

但是只要是公司出的App，就不会完全任由你白嫖，别人也要养活员工的不是，所以就会有会员或者买断机制。并且为了多端同步，云服务器的开销肯定也要你出一份力。

要花钱是一方面，另一方面很多人是不愿意自己的文字或灵感被其他App上传到云端的，不管他到底有没有扫描你的内容。

比如我本地使用的Obsidian，完全本地，多端同步靠私有的Github仓库，有丰富的插件可以折腾，绝对的够用，非常适合用Markdown的写作者。

那Memos有哪些特殊的优势呢？

开源、免费。这是最重要的，意味着你可以随意定制属于自己的Memos。
不依赖Markdown。可以用，但不用也没事，就和发朋友圈一样，写字+配图
数据本地化。写了一堆心得、感悟，随时可以导出Markdown
Api访问。支持通过自己生成指定过期时间的token来自定义其他的玩法，比如从微信直接录入到Memos中
可私有，可公开。人难免需要把自己的想法分享给他人获得共鸣，Memos也支持你分享某一条朋友圈

如上则是一些比较大众的优势

在我看来，Memos可以试做一个小型的知识库。同时，你的知识片段需要时常去分享出去验证，而不是一直躺在本地，此时Memos就显得十分便利。

在分享的过程中，别人首先会对你的内容感兴趣，其次也会好奇你的分享方式。最后说不定也能发展成为小群体之间的知识库，比如面向小区的植物类科普空间，大家可以分享下自己的日常干货。

日常使用时，PC端就使用Web页面。手机端我喜欢使用微信里直接打开链接，然后添加到浮窗。个人感觉这样要比App（Meo Memos）要好用一些，App里更倾向于早期一些基础功能，和现版本的Memos有点脱节。

找个长期的事做

Tue, 09 Jul 2024 00:00:00 GMT

平时经常会有周期性的摆烂时刻。

比如这一阵公司里活很忙，忙完之后，一停下来就不知道再干嘛了。

比如这一阵儿在写文章，写了几篇，没灵感了，写不出来了。

比如这一阵儿在搞副业，搞了点钱，但是觉得不满意，也不确定要不要继续做下去。

比如这一阵儿在打游戏，到了一定的段位，再往上有点难了，也懒得打了，又开始想能干点什么别的。

所以我在想，有没有一种长期的规划，能把平时空闲的时间填满。

本身虚度时光也并非是一件坏事，只是现在囊中羞涩，让你不得不焦虑，毕竟现在环境都这么差了，谁也不想要靠变卖家产来维持生活，肯定想着增加收入来维持当前的生活水平。

如果有充足的金钱作为后盾，那虚度光阴就是最好的选择，什么好玩玩什么，想干什么干什么，孩子爱干嘛干嘛，能保持一个不高不低的学习劲头就足矣。

所以焦虑的本质其实就是金钱上的焦虑，所以也不要想着什么做出什么技术上的成就，新技术懂多少，还是要先从什么能赚到钱出发，技术本身就是自己很擅长的事，什么时候都能重新抓起来。

除了赚钱，其实最长期的事儿就是锻炼身体，这个是你不管平时工作收入如何，心情如何，只要去做了，就会实打实的反馈给自己的一件事。

但人都是懒的，运动有点反人性，能坚持去锻炼真的不容易。尤其是有孩子的情况下，还要找个合适的时间去。

目前看来，已知的是闲鱼可以倒卖电子产品，货来自于中间商，中间商依靠我们这些下线，在老板那边低价拿货（承诺每个月帮老板卖xxxx台），拿了货再发给我们下线去卖，利润归下线，下线一次性最少拿xx台。

相当于老板是一点都不担风险的，出了货就拿到了利润。

中间商负责的是教下线如何闲鱼卖货，吃一笔一次性学费（就算是不教你，其实他自己也要卖货，但你无法获得老板这样的货源），也相当于给自己以后其他的副业项目背书，能参与这个项目并赚钱的，大概率也会参与他其他的项目，而且这批人还是被筛选出来的，能卖得动货的人，对于整个链条来说是个良性的循环。

另外因为发展了很多下线，承诺了拿大量的货，所以压低了进货价，这个进货价是不是也吃了一头，不确定。如果是我的话，可能会小吃一点，毕竟老板走量的，这种利润低量大的事儿，不吃白不吃。

其实还是类似于分销了，下线只是想赚点零花钱，只要这个东西利润可观，基本就回去做。不然你做其他的，其实也不知道能干啥

这个最大的问题就是在于，下线自己囤货了，卖不出去怎么办。

但是你卖电子产品，手里没有货，客户就要你的现场图，没有货还真是不好卖。好在一次拿小几千的货可以试水。

花时间研究赚不到钱的副业，还是花时间做个没人用的产品

Wed, 03 Jul 2024 00:00:00 GMT

对于副业和产品，两个都不沾的程序员，去搞哪个真是个天大的难题。

因为既不确定未了解过的副业能否赚钱，也不确定做出来的产品是否有人会用。

花时间在副业上，没赚到钱，但是能提升对副业的敏感度，不知道什么时候就上了道了。

花时间在产品，没人用，但是能提升技术之外的譬如架构、设计、推广之类的经验，说不定什么时候也能火一把。

真是难评。（当然，这里副业指的是网赚的那种）

比如我前一段时间。

起初，是有要还原一下小红书web端的想法。当然，只是为了在技术上表示自己能实现（最后也实现了他的效果。

先用uniapp里实现了一下两列的瀑布流，又用NextJS实现了动态列的瀑布流，又想用Vue实现一遍，我真是疯了。。

恰好，前一阵又和老婆谈论起孩子周岁请摄影师的问题。

家庭摄影师上门拍摄，一套是599 ~ 899左右，我们就在感叹人家这钱真好赚。

而且有的摄影师拍的并不好，但是人家却一直有单子，不知道怎么回事。

而且还在家里自己做宝宝吃的零食，也是线上售卖，看起来利润也很高。

然后就在想，我们自己能不能也搞摄影？（然后就只停留在了「想」这一步）

但是有摄影作品之后，要放置自己的图片，又想着做一个自己的展示作品的网站，展示形式就是防小红书的移动端，生成个二维码，这样就可以发给客户扫码看（想的是真多😤）。

不过幸好没动手做。

既然展示形式就是模仿的小红书，客户也是从手机上打开，那为什么不直接去做一个小红书的账号呢？

真的，我真是一个标准的程序员，每个想法的背后都直通内个大道：「我能不能自己实现呢」

老想着搞一个本地化的类似小红书用于承载内容，而实际上内容还没开始。😮‍💨

先把内容充实起来，技术方面的东西其实很快就出来，内容是最难打磨的。

而且在没有足够多的内容之前，其实是不能确定要如何呈现内容的，所以又回到了最初的问题：「怎样积累自己的内容」

虽然已经这样想了，但总觉得某些会有使用场景，会忍不住去把他做出来，就是不知道场景在哪里～～

不做吧，其实每天上班闲着也是闲着。

而且根据我的经验，假如想花一个月时间去做一个产品，但是怕做出来没人用，然后就没做的话。再回过头去看，这一个月还是会白白浪费掉。

因为一个人除了工作，总得有一个其他的爱好或什么事情把空余内容填满，不管是刷剧、玩游戏、运动、逛街、或者继续工作，你总得干点什么，不可能干瞪眼儿。

这样看的话，其实真不如把它做出来。

老天爷已经给了我时间让我去做了，我没做，我真该死啊 🥲

当然有别的副业需要时间去钻研，还是先去赚那个钱比较好。

而且习惯了被公司安排具体的活干，和自己想出一个能解决别人需求的产品，完全是两个方向的思路。其中唯一不用担心的就是技术问题。

有时候真的想有一个人，指着我说：「看，这就是全部的需求，你去给我做出来」

我仔细想了想，造成这种焦虑的原因，可能是自己得不到除了工作之外的正反馈。

也可以说太执着于追求工作之外的「钱」带来的反馈。

也有可能，这不是我的问题，可能是我平时所处的网络环境的问题（大胆甩锅一下）。

一部分人，追求赚钱，讲究利益最大化。然后就会自然而然的、苦口婆心的劝说那些还在认真搞技术的人，不要深入搞技术了，有什么投入产出比呢。

另一部分人，本来就是个咸鱼，混一混罢了。看到环境下行，巴不得拉更多的人和他一起摆烂。

以至于有时候会让我感觉，研究新技术、看底层原理、造轮子会产生一种负罪感。

因为代入别人的说法，确实没什么性价比，也只是个普通打工人，很难和老板穿到一个裤腿里，而且环境确实差，不确定性太大，所以时常有不自觉的排斥心理。

但转过头一想，不管别人是口嗨也好，为了自身利益也罢，其实都对我没有什么影响。

不管把我时间用在了哪里，最后的效果都会作用于我自己，无所谓什么意义，也不存在什么必须要有的反馈。

而在时间用的最多的方向上，其实就是在积累自己的内容，也许就会产生自己的产品。

打工仔请睁眼看世界

Tue, 07 May 2024 00:00:00 GMT

闭眼工作的时候世界是那么的美好，睁眼看世界的时候人人都想赚我的钱。

1

我是一个打工仔。

我的工作就是完成老板安排好的任务。

老板会给我缴纳五险一金，会每个月按时发我一笔钱。

老板说也不用我交押金，也不用关心他在干什么。

只需要用我会的技能，在规定的时间内，完成好他安排好的任务。

完成的好，甚至还会多给我钱。

不想干了，也可以把老板换掉。

于是我每天两点一线，在固定时间上班，在固定时间下班。

虽然这意味着上班时间被固定，但也意味着下班后我一定有自己的时间。

上班时间我只关注自己手头的事。

老板发什么我都只需要发大拇指👍🏻和收到。

同事可以不沟通。

沟通不好还有文档。

大不了拉个会撕逼一场。

反正大家都是一条绳上的打工仔，谁也别比谁高贵。

开会一天，一天工资到手。

干活一天，一天工资到手。

摸鱼一天，一天工资到手。

横竖都是一天，只要时间一过，工资就会到手。

工资日的前一天是我最开心的一天。

因为当天就要还上各种贷款。

这么说来，贷款就是为我这种打工仔设计的。

他知道我一个月发一次工资，所以让我一个月一个月的还。

不然为什么不是我每天都还，或者有了钱再还。

幸好我还能剩下一部分钱。

剩下的钱，

可以存下来；

可以和好基友吃顿好的；

可以买一张最新的显卡；

可以买 steam 新出的游戏；

可以买新出的皮肤；

如果不是江西老表，甚至可以娶个媳妇。

直到有一天，老板对我说：公司可能不太适合你了

于是我开始为自己打工

2

我变成了老板

理论上来说是的，因为我开始自己寻找赚钱的项目

五险一金彻底断了，失业金领起来。

我开始加入一个一个的副业群，但是他们都有入场费和押金。

我来到了一个自己完全不熟悉的领域。

该做什么全靠别人整理好的文档，当然，这也是我花钱买来的。

执行的不好，肯定赚不到钱。

执行的好，也不一定能见到钱。

因为师傅领进门，修行看个人。

赚钱是少数者的游戏，是 （努力+执行+数量 + 质量+ 头脑+视野+变通）x 赛道加持 x运气

我懵了，超过一个未知数的算术题，我向来是不擅长的。

现在一天24小时都变成了自己的时间。

醒着的时间在搞钱，睡着觉的时候在做梦搞钱。

同事们也都变成了网友。

以前骂一骂同事们，第二天他们还是会正常上班。

现在骂一骂网友，不等第二天他们就会把我拉黑。

但是手头事还要自己找。

不做点事是不行的。

不做就没钱，没钱就得饿一天。

做事就按大师的文档来做，先这样，在那样，最后就成了。

但这文档明显没有我那**产品经理做的详细。

于是我一个没忍住，跑到群里问了一句：这文档这个地方怎么回事，整不明白。

大师说我没有慧根。

我硬着头皮让大师替我解答一番。

大师沉默了。

大师麾下几个有慧根的弟子站出来了。

他们说这文档已经很详细了，一直都是这样的。

说为什么不思考一下是不是自己的问题，为什么别人能看懂，并且能赚钱。

我真的，气抖冷。

我去菜市场花一块钱买菜，卖菜大妈都不会给我一个烂叶子。

想了想，算了。

我删掉了不少于200字的不重复的问候。

这里不是电子竞技，不是祖安，不值得我浪费我的热情。

这个时候我突然有些想念我的老板。

于是我在群里发了一个大拇指👍🏻，并顺手把群折叠了一下。

赚到的钱乱花是不可能的

还得给下个月和下下个月的贷款预留好

绷得太久了，都忘了以前是多么的心安理得。

就像老王永远也忘不了叶菲莫夫的遭遇一样。

赚钱使我日夜不安。

我的灵魂里好像也有了一个恶魔。

它不停的对我说：人生不可空过。

可是人生，尤其是我的人生就要空过了，简直让人发狂。

还不如让我和以前一样心安理得的过日子。

30岁的身体，18岁的灵魂，60岁的心态

Mon, 08 Apr 2024 00:00:00 GMT

进可攻，退可守

我有一种感觉，到了 30 岁，人生才刚刚开始

1

30 只是个数字，因人而异，我的 30 岁也可以是你的 25 岁

对我而言，30 岁意味着经历了学业、恋爱、工作、结婚、生子这几件人生大事，同样也意味着以后肯定也还有很多我不知道的大事

现在看来学业和恋爱作为时间上占比 70% 的基础积累，仅靠义务教育远远不够。更不要说，甚至好多人 22 岁以前主线任务只有学业

要在剩下的8年里，完成情商、沟通、财商、情绪管理、时间管理这些重要素质的铺垫，还要外加对家庭的感悟，对教育孩子的探索等等，我觉得非常难。

以前总觉得大学毕业，开始找工作才叫步入社会。现在看来，从开始上学其实就是步入社会了。

开始和社会沟通，和人打交道之后，这些素质显得重要的多，并且并非天生就拥有这些素质。

这些不像是学业，是有教科书，有练习题的

大部分都是看似虚无缥缈的东西，能接触到这些，要靠平时看的书，认识到的人

ok，接触到了，算是第一步。

但生活不是考试，学习期间看的是考试相关的书，练的是考试相关的题，考起试也都是相关的知识，好好学是可以拿高分的

沟通，理财，时间管理这些我怎么去刻意练习呢？

沟通就是挨骂，挨批评

理财就是拿着饭钱不吃饭，省下来偷偷买点玩具，买点零食

时间管理就是晚上挑灯看小说，第二天白天照上课不误

况且，我现在是复盘的时候才认识到这些，当时没人指点，几乎不可能自我顿悟。能自我顿悟的基本都是狠人了。

以前老听大人们说，谁家孩子天生懂事，谁家孩子天生聪明，谁家孩子每个月吃的少花的少，还能剩下不少

现在我大概明白是怎么回事了

所有的技能都要靠言传身教

怎么理财，怎么沟通，怎么管理情绪这都是要手把手教的

没见过钱，没花过钱的人怎么理财？

只看到父母天天大吼大叫，不开心了就发泄，怎么管理情绪？

有问题不说，问就是我的错，谁会有沟通的欲望？

刻意练习达到的效果被其他人看到后就变成了一句夸奖。

像极了现在的成功学，只宣传结果，不宣传过程。

另外，虽然说对优秀的素质非常向往，但不得不承认，有些东西我是真的不擅长。但前提都是尝试后才知道的。

所以最有意思的点是：时至今日，我可能无法知道我的不擅长是因为没有早点尝试，还是天生如此

更有意思的是，就算重新编排了过去的 30 年，大概率此刻应该还会后悔

人生不如意事十有八九，此刻能认识到，还不去尝试，就是未来的遗憾

所以 30 岁只是一个开始，是意识到自己有那么多不足后，又重整旗鼓的开端。

最最重要的是，我此刻意识到的不足并想办法学习，思考，总结成自己的东西。对于孩子来说，从他开始懂事，我就是拥有某些长处的家长了，就可以在某些方面作一个榜样了。

我的过往虽不完美，但对他来说并不可见

2

18 岁代表了欲望，是源动力

今年是工作第 7 年了

现在每天上班的节奏就是，把工作安排好，然后尽快完成手中的活，腾出的时间来去学习和探索

因为工作时间比较久了，Vue 已经用了 7 年，比较熟了，在项目上基本上属于帮同事们解决疑难问题的状态

普通的业务需求很短时间就开发完了，搞一搞有难度的才能让我兴奋起来

这几年从前端学到了后端，云服务器也买过了不少，也学会了用 docker 去部署，自己搞个项目用一用已经不是什么问题

但是越是学习就越感觉不会的还有很多

也在思考要不要再去扩展到更广的技术面上去，因为不在一线城市，技术深度再深这里也用不到你，因为业务翻来覆去就是那些，所以技术不像一线那样卷

当然也不可能是一直和打了鸡血似的，中间肯定有停停顿顿，不然我早起飞了

因为学了不少不同技术方向的课/小册/视频，也在思考怎么把他们都沉淀下来

最简单的方式就是写文章发出来，但是看的人很少，所以我在想有没有更直观的方式，可以展示这些技术内容。

但最核心的还是文字版，不管是视频还是图文，都是另一种载体了

很多东西学了，也不确定在未来会不会在工作上用到，或者变成其他有价值的落地项目。但时间就摆在这里，不用肯定是浪费了

我也想用上班时间上几把分，下几把铲铲，可惜情况不允许啊

目前感受下来，状态要比 17 年刚入行的自己要好很多。既有了一些技术储备，还保持着热情。回看前两年也成长了不少，和自己比能保持一些进步，这就足够了，多的也奢求不来。

现在想来，我应该是属于谨慎的猫头鹰类的人，对严谨系统有一种狂热？

有源动力挺好的，接下来就是增加一些方法论，不要让自己的热情浪费掉。

一是方向，二是塑形。就像烧制琉璃一样，先确定好形状，再全方位的打磨。

在冷却前

3

60 岁代表了心态，是动态的佛系

最近加我的朋友比较多，当然我也挺愿意和不同的人聊一聊各自的想法

但可能是同样被副业困扰，有的上来就问我怎么搞副业赚钱，说自己已经被割了

先不说我能不能赚钱的问题，你这不是又要进一个被割的节奏了吗...

如果是想正经搞个副业的话，先尽可能的多看多搜，相信也能了解个七七八八

最简单的，去某鱼某多买点那种打包的副业资料，自己花点时间通读一遍，先把副业的玩法了解个大概，没有必要去网上找一个毫不相干的陌生人

你可以把副业当成一个项目上的业务一样去看待，要立项，要调研，要优化，要落地，要有 deadline，然后你就会发现，谁会买和怎么告诉别人来买的问题，顺着问题一路解决下去就可以了

还有的朋友，非常害怕自己要发展长期主义的话，几年下去看不到结果，怕浪费了时间和精力之后无法变现，就没有意义了

首先我觉得，如果要追求变现的话，为什么要选择做长期主义呢，短期有那么多变现的办法，花点门票钱，进一个社群，各种小项目挺多的呀。

其次，我理解的长期主义意味着我本身才是最有价值的产品，别人买单也是因为我是个靠谱的人才买单，要不怎么叫个人IP呢？每一天投入在提升自己的技能点、认知的精力，每一次更新的动态、输出的能量能够对他人有所帮助或鼓舞，长期积累起来才慢慢体现出来我的价值。所以大可不必担心投入几年没成效的问题，压根没那么容易坚持住，投入三个月不间断已经打败了99%的人了。所以，每一次对自己的投入都是有意义的，但这些意义确实需要时间去体现。

最后，没有收益这件事人人都怕。不是人人都能发现，不是人人都能坚持，也不是人人都能幸运。这都筛选了多少层了，我被筛选掉也很正常。

60岁的心态就是为日常的各种失败兜底的，当个普通人也没有错

守住主业，发挥优势，多去尝试，拥抱失败。这四条我觉得很重要，顺序也很重要。很多转型的大佬都是挂着以前的Title，大家选择起来也更愿意相信这些已经在某些领域做出过成绩的人。

另外，烦心事多着呢，犯不着在一个事儿上纠结，再说人生就这几十年，忍一忍就死了个屁的了

还有，以前总听说万事开头难，实际上“事“以亿计，不难的事多的很。不要被思维惯性骗了，只是咱接触的少，不知道而已。

有好心态才方便变通：“破守成规”

4

不动如山，动如雷霆

30岁的过往已经翻篇，代表不了以后

保持热情，摆正心态，多和在同样道路上觉得比自己做的好的人交流

不管是多少岁，都是开始

干就完了!

“无薪加班，最为致命”

Tue, 02 Apr 2024 00:00:00 GMT

“我知道你们都很辛苦，但是项目交付在即，大家为了公司再加把劲！！！”

1

相信各行各业都有加班这种现象

就拿我所在的互联网行业为例吧，我工作已经有7年左右，加班、出差、项目通宵上线这些都不知道经历过多少次了

有些大善人呐，去和客户谈项目

为了吹牛逼，啪，一拍桌子：“哥（姐），一个月，指定给您完成的漂漂亮亮滴”，“能做，都能做，都能实现，放心就行了，我们公司做这个做了百八十年了，有经验！”

回来公司给领导报喜：“成了~ 成了~ 拿下个大单”

回头，和客户合同一签，需求一梳理，直接就开始给研发部门分配任务了

开发兄弟们一看，这么些个需求，一个月弄不完啊

一顿开会扯皮，该做的没少多少，时间上也不能多给，人员也就那些，那咋办，加班搞吧

有些领导可能还会来时不时来加油打个气，表示和兄弟同甘共苦

但有些领导是真不当人啊，他趁着你加班，还要来说你不够努力，效率不够高。如果你够强的话，这些问题都好解决。然后转头再说加班是福报，是历练，有助于个人成长。

不是，领导，我那3k的月薪怎么说？？

你给我3w试试来，我直接住在公司，每天鞭策自己。这还没完，我还要鞭打同事，让他们也努力，也感受感受你的福报

领导在吗，怎么已读不回

2

还有一类加班方式

虽然你手里没活，但是你不能下班

为啥呢？

~~因为你的领导喜欢你加班的样子~~

因为你的平行部门加班很多，而你的领导和他们的领导又存在竞争关系，你们加班少了，领导很没面子，在上级领导面前无法提现出他的努力。

所以，也得辛苦兄弟们一下，下了班，在这做做样子，到点儿再走。

大家家里有事的，有特殊情况的，我也理解。这样，先给自己组长报备一下，再提个申请，就可以回家了哈。不过，咱们这部门评优，竞争也比较激烈，大家平时好好表现，争取下次能拿个好评分！

这个套路像极了高中班主任在重要考试的前一周不让上体育课的样子

“你们想上体育的自己去上就行，不想上的在教室里自己复习，另外上了体育课的后面两节课也上体育吧，不用回来了”

还有的，是单纯的不想让你比领导走的早（是的领导，你年龄比我大这么多，我肯定不能走的比你早）

走的早了是对领导的不尊重，是亵渎

搞的有一阵，明明六点下班，一定得等到六点半、七点才走

走的早了，心里还发慌，怕自己会不会太格格不入了，怕领导给咱穿小鞋

我明白了，这是让咱提前体验体验体制内的生活呢😅

3

既然加班避免不了，好歹的给点福利也行

要不给点钱

要不给点调休

报销一下打车费

报销一下餐费

都行，你TM别什么都不给啊

白天顶着身体压力，坐一整天，腰酸背痛，没空提肛

晚上还要上点精神压力，血压反复过山车，一边心里痛骂，一边自我开导

让本就不堪大用的身体雪上加霜

这下好了，不用担心35岁失业了，我活到这个岁数都够呛

一边觉得自己身体越来越差，一边也想抽空锻炼一下身体

但是一下班身体就想被掏空，提不起劲儿来

再看看别人写的文章：“每天你连半小时的时间都挤不出来吗，多想想自己的问题”

是啊，我怎么连半小时都挤不出来，我真该死啊

然后我又转念一想，难道我的累都是假的吗，难道上班累下班就马上能打起精神来吗

况且，每天保持健身、运动的人，人家的生活作息能和咱一样吗，收入就更不用提了

太惨了家人们，越是牛马，越被人当牛马，停下来还要被抽两下

4

95后身上栓的东西太多了

整顿职场还得看后浪

入职前我唯唯诺诺，入职后我重拳出击！

平时我们看的都是《xx从入门到精通》《程序员腰椎康复指南》

而人家看的是...

我人傻啦，这不是玄幻小说那一类的吗

我还在我在第几层，别人在第几层

他直接反问一句，怎么了没有电梯吗，然后坐着电梯反复横跳

我见了太多老实人，对于领导的需求，来者不拒，根本不知道怎么拒绝

领导也喜欢就逮着好欺负的使劲薅

我真的想说，兄弟，没看到领导每次抽烟，压根就没想着你吗...

说出了多少人心里憋着的话

哈哈哈哈，让领导自己去想

领导直接蒙了

以前都是自己当谜语人，让员工去解谜

现在员工个个都是谜语人

这位更是人间清醒，已经是10后了，不是00后了

脑袋瓜子转的比咱快太多了

记者直接满头大汗，本来准备好的词儿是一点也用不上了

多少年的套路了，怎么现在这么难用了啊

难道是该迭代打法了？

玩归玩闹归闹

人家00后，10后有事是真整顿

咱也就看着人家整顿的爽，假装自己也出了口气

回过头来还是该加班加班

熬出头的，当了领导的，刚想着征战职场受的苦也让新步入社会的新人接受一些毒打

没想到自己也要成了被整顿的对象喽

当一个程序员看到小米汽车发布后，竟然产生了这样的连锁反应

Mon, 01 Apr 2024 00:00:00 GMT

1

最近被铺天盖地的小米热搜给包围了

不得不感叹，雷总的营销手段之高，网上的曝光量如此之大，小米汽车到位之后，想去试驾的人也一定少不了

试驾的越多，只要车没啥大毛病，购买率就越高

况且现在汽车行业的各项指标都是有数的，小米只要对标着来就错不了，真正的买车的主力，估计还是没那么了解汽车的群体

外观漂亮，机械素质高，驾驶感优秀，再来点智驾功能，价格只要在购车人群的预算内，很难说会越过小米汽车

不管怎样，对于一个消费者而言，还是很看好小米汽车的，希望早日让汽车的性价比提升到和小米手机一样的高度

2

虽然小米汽车热度很高，但程序员嘛，在公司摸鱼还是以摸文字版的信息为主，不敢太过造次

再个，程序员摸鱼的论坛，多少还是和微博这类阵营有点区别的，也不仅仅是热点新闻

这不，前几天我就看到了一个关于小米汽车的3D网站，打开网站一看，好家伙，我直呼好家伙

这效果，你说这是小米花钱打造的我都信

太丝滑了实在是

顺着网站的介绍，又摸到了作者的其他作品，还有网页版原神，以及一个杭州亚运会水墨风宣传片

好家伙，是个真大佬

把玩了大佬的作品之后，感觉整个人都被点燃了，什么时候咱也能搞出个这个来啊!!

此刻我的身体已经开始发热，感觉血液已经冲上了脑门

仿佛鸣人在变身九尾

艾伦在变身巨人

大古在变身奥特曼

耐摔王正在以雷霆击碎黑暗

**战斗!!! 爽!!! **

我必须马上开始学习webGL!

3

说搞就搞，我立马就打开了vscode，准备开始我的webGL学习之旅

目前用的最多的就是Three.js这个库了，那我就从它开始搞起

先找到官网，快速过一遍Api，了解一下基本概念

过完了，直接开始手搓!

不会也没有关系，现在有了AI辅助，在完全不懂的情况下，完成一些demo也不是问题，这里我用的是月之暗面的Kimi

先给AI设定一个背景，然后表达出自己具体的需求，比如，我就是想用threejs加载一个3d模型，然后给3d模型尝试换色

先根据官网，把项目搭建起来，然后根据Kimi的提示，一步步的完善代码

很多像是做着色器/uv/shader这些名词，不懂也不用先深究，目的是先搞个3d模型出来让自己爽一爽

看文档得知，3d模型推荐使用glsl格式的模型，于是我先去找一个3d模型下载到本地来

找到了一个 3d模型网站，然后选择免费的模型，大佬搞个小米su7，咱也别太差，弄个奔驰大G就行

然后把尝试在代码里把模型加载进来

当然，这期间不是这么顺利的

其中很多坐标系问题，模型加载不顺利，灯光忘记加了，摄像机位置不对这类问题就一一对照官网文档和AI的提示，也没有花费太多时间就搞出来了

模型加载出来之后，我先尝试给模型换一个颜色，在AI一遍一遍的提示下，始终无法做到像是真实世界汽车改色一样的效果

我就怀疑是不是我的模型有问题，因为我看到3d模型的文件里，只有一个mesh，只要一改颜色，就整体全部都改了，改完的颜色就像是在ps里给他硬生生叠加了个颜色上去一样

但是我又对3d模型里的各种专业名词不太了解，只靠自己猜测，恐怕解决不了这个问题

而且用AI把控大方向的编码是没问题的，太具体的需求它也解决不了，除非把所有关联的上下文全都喂给他，但是这样又不太现实

于是我就找了个搞3d的老哥请教了一下，大概了解到了，如果要精细的实现控制只在某些部位比如车身上变换颜色或者痛车，模型就得分为多个mesh才行

而要实现精细的特效，多半要自己手动实现shader，只用threejs可以实现一些的效果，但达不到自定义的高度

好吧，看来是要继续深入探究了，不过这不也是开了个头嘛~

4

既然需要shader，我就去了解了一些shader的概念，以及一些shader的教程，先让自己对shader有个大体了解

一顿恶补之后，好歹知道了顶点着色器以及片段着色器的概念，这时才知道Kimi给我写的材质里传入的那一堆代码是什么东西!

但这类野文十分稀少，连掘金小册都只有一本

为了便于让自己更好的学习shader，我就花了十来块钱，买了小册，利用上班时间和业余时间，闲里偷忙，开始跟着作者实践起来

学习新东西，还是尽量找到一些别人总结好的教程，不管是付费的还是免费的，只要是总结成体系的，肯定是比刷野文要吸收的好一些

大概花了两天的空闲时间，我刷完了这本小册，对于一个数学已经忘得一干二净的人来说，还是十分烧脑的

但我还是硬着头皮把它看完了，倒不是说完全学会了其中的各种函数，这毕竟是有数学门槛的，但我只需要理解什么时候要用，能实现什么效果即可

而且作者的实战项目里，还会教一些他在用的框架，vscode插件等等，这些东西如果靠自己搜，估计很难搜到

所以说，找一份别人提炼过的教程来学习，事半功倍，能接触到不少相关的库和技巧

小册最后，作者也推荐很多shader的相关学习资源，正好我还不理解的部分也想着继续深入学习一下，于是我就一一打开看了看，尝试了一下工具，收藏起来

然后我就发现了Essense of Linear Algebra 这个视频，b站叫线性代数的本质，因为shader计算的背后是线性代数这门学科，这个教程以可视化的方式很形象的阐述了线代的主要知识点(向量/矩阵等)

本来我没想着从头再学一遍线代，但是我还是打开看了看

这一上来还没看到内容，弹幕的夸赞就让我知道，可能是捡到宝了!

5

我的目的是理解线代和计算机图形学的关系，同时帮助我加深理解那些sdf函数是如何产生神奇的效果的，而非真的去学习计算的那部分

这个教程真的很符合我的需求，让计算机去做计算那部分，我又不需要考试

目前这个系列我还在不断地学习中，作者的教学及动画也正如他所说的，让我对于这些概念有了非常直观的概念。

视频真的非常优秀，感觉刚上大学，或者上大学前，非常有必要提前看一看这个视频，对学习会很有帮助

结合之前在shader小册里学的东西，能够更好的理解shader中这些数字的运算是如何对应到屏幕上的颜色的，以及为什么产生了这样的效果

6

btw，整个连锁反应，没有超过三天，并且还是在工作日。

因为一个炫酷的网站，真的学到了很多自己未知领域的东西，技术果然还是一如既往的好玩！想必这就是最初做技术的初心和乐趣所在吧。

但是话又说回来，这三天的收获也可以说什么都没有。

因为threejs只是开了个新建了个项目，shader也玩不了6，线代也考不了高分。

Math.floor(技术方面)确实是毫无收获。

但是我又一想，也许这种学习和挖掘的能力对我来说更重要，之所以感觉没用，是还没把它用在更多或更该用的地方。

简单来讲，就是还没靠技能赚到钱，钱对人的激励永远是最大的。

那就继续探索和努力吧。

做程序员 7 年了，你改变了多少

Sat, 23 Mar 2024 00:00:00 GMT

研究表明：如果感到文章不符合自己的认知、价值观，或许是阅读姿势导致的

专家建议：将手机朝南倒立后，撕掉防窥膜，在其上方57°方向俯视阅读，方能感到舒适。不方便将手机倒立的，也可以自己倒立。

1

作为一个程序员，工作之余，难免会产生要做一个项目的想法。

因为技术本身上限极高，我们时常会看到某某同学因为技术优秀，进了某某大厂。某某大佬又出了一个什么牛逼的开源框架，短短时间已经上千或上万star。另一位大佬独立开发，一人企业，已经实现财务自由。

还在苦逼搬砖的我们，也会有搞个大的出来的想法。

虽然大部分时候都是拉了坨大的。

所以有时候我在思考，如果你只面向面试做准备，而实际水平别人并不知道，成功入职后如果不是需要自己独挡一面，又有多少人知道你的真实水平？

或者说有多少人在意的你真实水平？

或者说在意的人会不会只有和大家一样的最普普通通的打工仔？

领导只关心能否按时交付项目，拿到回款？

再回想一下，你在面试的时候有没有在介绍项目的时候告诉面试官说，这是你自己独立开发的项目，实现了什么什么功能。而面试官只关心这是不是在公司正式环境中使用的，有多少盈利，你说不是，没有，是自己实现着玩的。然后就没有后续了

所以，这个项目是不是自己一行一行敲出来的，或许没那么重要。

2

大部分人是靠第一印象（也就是面试）对我产生一个概念，所以我的目标就变成了在面试时给面试官留下一个我可以胜任他所招聘的岗位的印象。

于是，我要做的就是以下几点了

①是刷各种面试题、八股文

②是整理自己的话术，如为什么离职？对自己的职业规划是什么？你的期望薪资是什么？

③是调整好心态（克服心理障碍）

以上三点还有个前提，就是大部分情况下，还是需要自己有点东西。

对症下药的三点只是为了给自己谋取入职机会、更高的薪资。

如果一个木桶，短板过于短，再灌水水位也高不到哪里去。

有经验的人可以一眼识破被包装的，但是会不会点破，要看被包装的人做了什么。

当然，绝对不能排除这个世界比你癫狂后还要魔幻的许多。

也会有你要空手套老板，而老板or领导也不关心你是什么状态，只要能把业务兜住就皆大欢喜的机会。

各种专项的培训机构或个体不就是干这个的么，你想面试大厂，还会打包卖给你一个内推机会。

现在看来，这个项目是不是我敲的好像都不是最重要的了。

重要的是，我熟读了这个项目的源码，完全了解了其中的技术实现方式和业务内容，能按照自己的理解讲述出来。

学习知识就是有这个好处，只要你今天能从自己嘴里讲出来，那别人就不关心你是几年就会学会的，还是刚刚学会的。甚至还会自己脑补你肯定已经厉害很久了。

3

换个位置来想，如果我是领导或老板，我当然希望自己是个善解人意、有领导力、有情商、有技术的好领导好老板。但这恐怕都是建立在公司能平稳运行，收入不愁的情况下。如果说是艰难时期，我的基本任务恐怕是要保证自己有收入，保证底下一群人有饭吃。

假如说费了九牛二虎之力和客户谈到了项目，我会希望项目能顺利交付。如果说底下有个刺头，在项目攻坚期间，就是不服从管理，还私下在同事间传播消极思想，恐怕我也会把他优化掉，因为这种情况下首先就是考验自己的管理能力。再个，搞不定的话自己都没饭吃了，谁还会关心被裁的人呢？技术换谁来做都可以，但这个项目必须得有人能谈成和推进才行。

再换回位置

“我在工作岗位上矜矜业业，公司竟然还让我无偿加班，还有那个啥* 领导这么多功能，就给这么点时间。就这还不一定有作为一个有骨气的技术人，这能忍？直接到某金的发一个《点赞xx，我提桶跑路》”

“别说了，每次接口都调不通，我还得跟着加班调，哎（此处包含30+程序员的一生”

“别提了，这年头能发工资就不错了，你没听xx公司，裁员裁了这么多人吗”

“......”

两个位置思考的内容相差很大，但都是围绕自身利益。

所以如果有人教我们要遵守秩序，要有道德，要有契约精神，要做个好人。

或许也要时刻注意下，是谁在教。

4

那这个项目到底还做不做啦？

要我说，如果手里能变现的副业，哪怕再少，也把单纯只是情怀的项目放一放，先把副业继续搞起来，最好能全自动。

如果是没有，但是还在探索，可以和自己的优势结合起来，用最少的精力完成一个闭环的项目，既了却了心愿，又能踩不少赚钱的坑。

如果是没有副业，也从未行动过，但课报了不少，这那的知识付费每次都少不了。

那我觉得还不如去接单，给别人写代码，用时间和精力换钱。

别老听别人说要做复利，要做睡后收入了。

想想自己冲动过几次？持续了几次？付出了多少？又得到了什么？

都不如把钱拿去自己消费了。

快醒醒吧，咱自己就是人家的收入来源......

5

总结一下

① 自己摸清自己有多少东西，有个大概了解。不够用，就去学。够用，就学会包装自己

② 面试时，看看别人需要什么。对症下药，做出有用的东西，整理归纳总结，只要能说出来就是自己的。

③ 人的精力是有限的，先停止内耗，再把精力用到合适的地方。至于用到哪里，用多少，需要自己刻意审视，保持头脑清醒。

④ 多换位思考，分清轻重缓急，不要砸自己饭碗

⑤ 觉得太累了，就休息，不要在累的时候做决定

任何别人的经验，都是建立在别人的经历和认知之上的，一般对自己不会产生实质帮助，最多只会产生一些精神、情绪上的价值。

所以，切勿入戏。

2024年了，副业可能还是要慢慢做

Fri, 22 Mar 2024 00:00:00 GMT

1

2024年了，这两年大家可能都不太好过

因为好过的人他可能是忙于工作或赚钱，没空在各大平台矫情，也没空听别人矫情

什么？你说你是上班时间没事干才刷的文章，请不要在评论区告诉我，谢谢您嘞

当然，我特指的是互联网企业，其他行业我也不太清楚

毕竟我妈前几天坐滴滴顺风车，随便碰到一个乘客，说自己是个销售，江苏人，月入5w，每个月天南海北的旅游，最发愁的事情是去了一个地方后要玩什么才好玩。

虽然我也惊到了，但我内心毫无波澜。但我妈十分吃一套，这个事到后面少说要被她再翻来覆去说几遍（同款老妈，请举手）

这两年互联网行业，铺天盖地的都是降本增效，一开始这个词还没辐射到二线三线城市，或者是还没辐射到中小厂，但到了今年，应该大部分需要自己努力谈项目的公司都把这个词列为了指导思想。

运气差点的兄弟，可能已经经历过了1-2次裁员，运气差点的里的运气好点的，还能拿个N+1。

运气好点的，也每天被网上的各种焦虑气氛搅乱了心神，生怕有一天会一刀砍到自己头上。所以不得不开始研究起了网赚的副业，给自己多留一条后路，顺便幻想一下靠副业大富大贵的那一天。

反正我现在是看到一个什么帖子，名字叫xx副业，月入xx，很难忍住不点进去，万一能搞呢？万一成了呢？是幻想也是希望。

2

在搞副业的道路上，花了有几个月的时间，接触到了不少副业方向，现在体会下来，大部分其实和做技术是一个道理。

作为一个入行时间有快7年的前端，只用vue，你要说问我react好不好学，好不好找工作，我也会告诉你，只要有一定的学习能力，先看看react文档，再自己多下手去敲几个项目，上手很快的，找个工作也不是问题，问题是给你开的薪资多与少。

副业也是一样的，你让一个入行很多年，已经有一些成功经验的师傅，给你讲副业怎么赚钱，怎么操作，师傅直接给你出一个极为详细的sop，你看后直呼nb。然后师傅再告诉你，师父领进门，修行看个人，你要有实操，要把手弄脏，要有执行力。再对比我给你的sop文档，赚钱不是问题，问题就是你赚的钱多与少。

当然更重要的是，你和你的师傅只是网友，他成没成功、是不是真的有经验你也不知道，sop出于谁手也有待商榷，有些师傅也不愿或不能公开他的账号供你参考，全靠自己自适应，靠信仰的力量，你只要相信相信的力量....

3

由于我比较懒，大部分项目，我操作了一下，觉得不适合自己没有再继续尝试了，感觉这个东西是比较需要前期的正反馈来刺激自己持续产出的。

但我初衷是在工作之外找一个能带来一份额外收入，甚至是睡后收入的副业。盲目的冲入一个自己毫无了解，兴趣大小全看有无反馈的副业里去，如果真的丢了工作，那个副业其实就变成了主业，接下来要做的就是要逼自己长期做一个比起以前还算擅长的工作但现在完全陌生的全新工作，哪怕在互联网领域又重新上岗，心态上恐怕也不会多么纯粹了。

当然这是一个假设，也是为自己没能在一个方向上坚持下来的说辞。

话说回来，就算觉得不合适，还是要不断的尝试的。因为大部分情况下，可能不知道自己怎么真正喜欢什么，是被时代推着走的。既然时代把我推到了现在这个环境里，那我也只能尽快适应。

兜兜转转一圈后，还是写写文章吧，多看多写，想起什么来写点什么，记录一下这几年技术方面的积累，记录一下自己的所思所想，也顺便蹭点流量主的收益。也尝试了AI写作，写的是快，量大了也能时不时爆个10w+（约50元/1w），就是没什么营养，我自己是不会看这种文章的。并且我极少主动取关一个公众号，除非他一直发不对我胃口的文章。

一开始给自己定的是一周两更，因为当时工作屁事没有，全是空闲时间。大把时间花在了搞搞新奇的项目和写文章总结上，但是后来白天工作量一上来，晚上还要看看孩子，再加上自己很懒，执行力不高，过完年后基本就断更了。现在又调整了一下，重新写起来了，扩大一下选题，克服一下心理洁癖，多存几篇存货，反正都断更了，也不差这几天了。

4

当然，如果不是开始探索副业，找到了一个圈子，并且有人愿意交流，或者你能从别人的交流里得到有用信息，也确实不好给自己一个定位。因为这个定位是在有压力的环境下，有目的的给自己确立的目标，不同于在舒适安逸环境下的无意识输出和积累。所以花点小钱，加入圈子，是我走的第一步，到目前看来，没有踩雷，也没有被割。（有需要的，可以加我Vzzdaddy577了解）

但目前看来，普通人能接触的，大部分能赚钱的，还是靠分销。

作为被分的一份子，要量力而行，什么训练营都参加只会害了你。如果别人的项目能一直扩张，恐怕别人不会来教你，赚钱没有嫌少的。

我纯纯不合理猜测啊，你随便看看。

一是项目扩张有了阻碍，无法再更进一步。

二是他开训练营分销收入和他自己做项目收入相比，至少收入够可观，费心力还少。

三是你是他赚钱的其中一环。开训练营、拉群只是为未来更多的训练营以及给其他和他一样开训练营的人圈一批优质的韭菜。

因为优质的韭菜是不会认为自己是韭菜的，只是觉得自己离成功还差了点什么，或者认为这点钱不会影响到自己，至少是觉得很值。

个体间的参差，让钱流动了起来。

需求才有市场嘛，都是你情我愿的，我觉得我可以理解。

所以，不管是搞什么副业，实体也好，网络也罢，都是为了让生活更好。

但如果此刻你的焦虑已经影响到了你自己，不如先缓一缓再重整旗鼓，因为在情绪不稳定的状态下做出的决策一般都是错的，不如先让自己清醒下来~

当然，慢，只是出结果慢，不代表你此刻什么都不做

未经探索的副业，也许表面看起来都不靠谱，因为有人已经在里面赚钱了

30岁程序员，已经在副业的海洋里遨游了

Mon, 18 Mar 2024 00:00:00 GMT

1

一个普普通通的工作日

我又在工位上摸鱼

但这次我摸的有点不自在

想当年，正赶上互联网红利，工作大把大把的挑，喜欢哪个去哪个

可如今，随着年龄的增加，时代的进步，人生大事的一件一件的打卡成功，让我也难免焦虑起来

倒也不是怕老婆孩子吃不上饭

也不是怕房贷车贷断供

主要是怕我这满腔热血和才华无处施展啊

2

焦虑，想搞点事，但又不知道搞点啥。

先刷刷手机吧

可能不是为了刷手机，但是确实不知道要干什么。

可能知道要干什么，但是下了班了就是懒的干、不想干（虽然上班时间也没干啥）。

行，刷手机就刷手机吧。

打开App，推送的全是《2024年了，我劝大家多做两手准备》、《我，xx岁，xx副业，月入xk》、《大家做好3年内失业的准备》

很好，里应外合，继续噶掉我这所剩无几的韭菜！

让我来看看怎么回事吧，先加个群，跟着搞一下，反正才9.9

好家伙

100个人里有一个人跑通了副业，然后剩下的99人都在各种付费课程里徘徊。

主打一个先付带动后付

什么？你还没找到适合自己的副业？

没关系，我这里还有一个帮你开拓认知的大师，你只需付费xxxx，就能加入他的陪伴群，还能获得xx%的分销权利。

要知道，人很难赚到自己认知以外的钱，所以提升认知是很重要的。

当你不知道投资什么的时候，投资自己就对了。

另外，你不买没关系，几天后，价格就会升到xxxx。

我：卧槽，说的太对了，早买我还捡便宜了呢

赶紧掏出我15号刚发的窝囊费，狠狠的投资上自己一笔。

30年河东，30年河西，莫欺少年穷。

你可以很赚，但我永远不亏。

上了赚钱的快车了

这不好起来了吗

码头的薯条已经看不上了，不得再加点可乐和汉堡疯狂一把啊

啊哈哈哈哈

很快啊，大师也出了一个训练营，仅需xx，因为我是尊贵的陪伴群成员，只需要9.9就能加入，还能获得100%的分销权利

我去，真的良心，9.9还没到一杯奶茶的钱。

搞起来。

3

在我的不懈努力和大师的提携下，终于，我赚到了工资以外的第一笔钱。

激动的心情无以言表！

先给大师发个红包感谢一下吧！

要不是他我还真不知道还能这么赚钱！

因为我能力出众，被大师邀请，开始在各个群里做分享，讲述我如何从一个普普通通的程序员，赚到自己的第一笔钱。

效果很好，大家纷纷被我吸引。

因为相同的职业，相同的背景，我都可以，他们也想知道自己可不可以

很快，微信里冒出十几个加好友的请求！

我心甚慰，加上之后挨个介绍训练营项目

苦口婆心，没办法，谁让我是真心经历过呢，那真是实打实的获得了好处

我现在是纯粹的利他，顺便还能利己啊

最后，成功拉新x人，获取一笔佣金。

4

但是有个小伙，加了我之后，也不报训练营，看起来很犹豫。

仔细一聊之后，发现是个有想法的人

正好啊，大师最擅长拓宽认知，我转头就开始循循善诱的推销起来

当然也不能说是推销，我这不也是在帮他吗

他扩宽的了认知，学会了赚钱

我拿到了佣金，大师拿到了学费

三赢！

...
...
...

等等

这个人怎么有点熟悉。。。

5

如果你已经忘了自己是要去码头整点薯条，至少还是要有在人们头上拉屎的乐趣

另外，赚钱就是这样，任何方式，只要合法都不磕碜，之所以觉得难以逾越心里的障碍，是这几十年环境对人潜移默化的影响，可以类比各类丑陋习俗。

如果直接给你500w，你一顿规划之后也是要回归平静、安逸、祥和的隐居生活。(注意，是真的有了500w之后的假设，而不是空想)

那么恭喜你，你现在只需要把心态调整到极致，就已经在过拥有了500w之后一样的生活了。（就现在，马上去人们头上拉屎！）

Astro建站入门指南

Mon, 05 Feb 2024 00:00:00 GMT

为什么要自己建站呢？

我想到了几个原因：

一、快感：建站类似做产品，也是一种学习后的实践。有一种刚看了一个做面包的视频之后，马上自己动手做出来一个面包，然后竟然还不错的快感。

二、正式感：相比于投稿到各大平台，自己建站不用考虑文章的字数、内容、题材等问题，减少了一部分焦虑感，但也是正儿八经的发布到网上给别人看，比起写在自己笔记软件里的碎碎念，发出来更有正式感。

三、信念感：建了站后，相当于画了一个自己的地盘。往里面发文章，那叫充实自己。网站名称，那叫个人品牌。网站 LOGO ，那叫个人形象。网站内容，那叫个人 IP。想想就有一种无比充盈的信念感，让人忍不住就往下跟着建站了。

说起信念，正好啊，快新年了，提前给大年拜个年，祝大家新年快乐👏👏👏

框架选择

建站有非常多的选择，如：WordPress、Hugo、Hexo、vuepress、jekyll、halo等等，我用过其中的部分，但今天选择的是 Astro。也不要问我为什么，想选哪个选哪个。

一般建的都是博客站，用来放一些自己的文章之类的。但作为一个程序员，还是多少希望他能玩点花样，但也希望他可以开箱即用，开箱即用基本上大部分框架都能做到，但是每个框架的花样确是不同。

Astro 开创的群岛架构，可以很好的满足我的需求，在不想折腾的时候，我就找个好用的模板开箱即用。想自定义的时候，就直接现代前端框架 Vue、React 、SolidJS、Svelte都整上。

以下是群岛架构的官方解释：

“群岛” 架构的总体思想看似简单：
在服务器上渲染 HTML 页面，并在高度动态的区域周围注入占位符或插槽 […] 
这些区域随后可以在客户端 “激活” 成为小型独立的小部件，
重用它们服务器渲染的初始 HTML。 
— Jason Miller, Preact 的创造者

**在 Astro 中，“岛屿”指的是页面上的任何交互式 UI 组件，知道这一点即可。

在 Astro 中，每个岛屿都是一个.astro 文件，有很多模板可以使用，而且官方文档支持中文，且很详细。所以这里我直接跳过了新建项目部分，可以去官网👈上了解Astro

模版选择

使用 Astro 需要 Node 环境支持，这一部分也需要自己去下手准备！！！

由于我们想要的是搭建起一个博客站，如果起步过于繁琐，很容易劝退，所以我们优先找一个好用的模板来快速启动，毕竟不是每个人都是开发者。

官网上列举了全部的 Theme 👈，大概有一两百个。我没有全部看下来，因为如果全看下来之后再选一个好看的，大概一天的摸鱼时间都不一定够，那第二天还会不会接着搞都不一定了。

于是我从免费的第一页里挑一个中意的，原则就是：简洁，但该有的都要有，也不能太简洁。

最后我选择了AstroWind👈 这个模板。由于语法上有一些差别，再加上全英文内容，还是要花一点时间改造一下。

模版修改

全局配置

全局相关的配置都在 src/config.yaml 里，分为了几个部分，还都挺有用的，挨个来看一下。

site：主要是用来设置你的站点名称、地址
metadata：SEO相关的
i18n： language需要改成zh
apps：是关于 blog 也就是文章渲染相关的，不改动也可以用，后续可以自己微调。
ui：主题可以切换 light or dark，主题的颜色变量也可以自己配置。直接拿来使用的话，可以不改。

导航栏

跑起来项目肯定第一时间是点一点导航栏，看看都有什么内容。配置文件在src/navigation.js 里，

配置内容我已经改成了中文，这样看起来会比较好理解。

这里的扩展下拉菜单的配置位置，会对 src/pages/landing 产生影响，原因是landing 里的页面是通过 src/layouts/LandingLayout.astro 渲染出来的，这个页面打开后会有一个新的导航栏，下拉菜单作者默认取的索引为 2 的菜单，所以需要手动改一下

底部Footer

底部的修改主要集中在 src/components/widgets/Footer.astro 中，比如也许不需要很多 links，看起来像是企业的官网似的，就可以打开这个页面自己注释一下。

文章内容

文章放在 src/content/post 下，一般是 md ，也支持 mdx。

md 文件中顶部会在三个横线中声明一些元信息，这些信息会在网站中用到，并渲染出来。下边是我复制的项目里的 md 文件的元信息。

---
publishDate: 2023-07-17T00:00:00Z
author: 枣把儿
title: AstroWin123131
excerpt: While easy to get started, Astrowind is quite complex internally.  This page provides documentation on some of the more intricate parts.
image: https://images.unsplash.com/photo-1534307671554-9a6d81f4d629?ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D&auto=format&fit=crop&w=1651&q=80
category: Vue
tags:
  - astro
  - tailwind css
  - front-end
---

其中publishDate会用作排序，因为首页有一个功能，会展示最近的几篇文章，是取的这个时间。

作者会显示在文章列表和文章详情页，分类和标签也同样会显示。

文章分类

在文章内使用category可以给文章分类，同时在导航栏中可以直接选择某一个分类进行展示

在 src/navigation.js 里可以配置导航栏，比如想配置一个页面，放全部的和 Vue 相关的文章

点击此下拉选项后，就可以打开一个只有 Vue 分类的文章列表页

同样的，上上图中的 href: getPermalink('astro', 'tag') 就是打开一个 tag 为 astro 的文章列表页。

有了分类和标签功能，这个网站承载文章基本就足够了。

使用图标

这个项目的图标库👈，使用的是@iconify-json/tabler，是安装依赖时已经下载好的。

使用时可以在 pages/index.astro里找到一个 Icon的注释。 name 就从图标库里复制出来直接使用，class 支持 tailwindcss 控制大小，color 控制颜色。如：

<Icon name="tabler:alert-square-filled" color="blue" class="text-md" />

如果需要其他图标库的，也可以自己加装。

其他

大家可以打开在源码，再借助 Vscode的TODO tree插件，快速查看所有标注点，根据自己的喜好进行修改。

打包和部署

打包命令和其他前端项目一样

pnpm build

打包后会生成一个 dist 文件夹，里面是打包后的静态文件。页面被编译成了单独的 html 文件，图片文件已经被转成了 webp 格式。

可以扔进自己任意服务器里，也可以选择其他免费的托管服务。

比如Readme 里的 Netlify和 Vercel，或者 Github 本身，这部分内容就不展开讲了。

源码地址

模板自取👈 源码中有部分中文标注，可以帮助你理解项目结构。

另外对模板的自定义程度有限，可以理解为本土化注释了一遍，因为再继续改造也不一定所有人都喜欢了。如果你也正在使用 Astro 建站，有困难的话可以在文末联系我。

以上就是全部内容啦👏

小结

本文是对 Astro 建站的一个不入门指南，相当于推荐了一下Astro，以及我自己在用的模板，目的是为了方便非前端出身的朋友快速上手。

如果对你有帮助的话，欢迎点赞和关注我～

我是枣把儿，一个正在扩充全栈知识库「早早集市」的开发者。欢迎在公众号「早早集市」找我交流～

使用puppeteer爬取掘金个人信息

Mon, 29 Jan 2024 00:00:00 GMT

引言

上一篇文章《使用puppeteer爬取掘金热榜》里，用了puppeteer的一些基础语法就完成了数据的爬取，这种可见即可爬的方式对于普通的使用者在感觉上来说，还是非常可靠和实用的。这次依旧是选择爬掘金的个人信息，但绕开了最麻烦的一步。

绕过登录

登录里比较麻烦就是验证码，有滑块、数字、数学计算等等多种多样的。

由于爬取的目的一般来说只是不太方便打开目标网站，或者要关注的网站太多，需要聚合一下每天刷一刷，所以对爬取的速度并没有太多要求。比较重要的是拿到数据后，如何进行可视化，所以就又回到了前端界面优化的问题上了。

所以我这里选择手动登录，并且之前使用的puppeteer这个库，现在换成了puppeteer-core，我用它来控制现有的chrome浏览器。

还有一个隐形的好处。比如有一个好朋友也有类似的需求，而他不懂技术，把程序打包成二进制给他之后，他能看着浏览器一步步的操作，反而会感觉更安心一些🤔

开始改造一下上次写的代码。

连接现有浏览器

因为不用默认内置的浏览器了，所以需要先打开自己的chrome浏览器，然后获取到浏览器的调试信息，再进行连接

const browser = await puppeteer.connect({
      slowMo: 50,
      browserWSEndpoint: address,
    });

获取address前，需要先用debug模式启动chrome，以macos为例，启动一个9222的端口号

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome  --remote-debugging-port=9222 --no-first-run --no-default-browser-check --user-data-dir=$(mktemp -d -t 'your_chrome_data_dir')

如果是windows，dir路径需要是一个存在的路径

文件路径/chrome.exe --remote-debugging-port=9222 --user-data-dir="your_chrome_data_dir"

启动成功后可以通过GET http://127.0.0.1:9222/json/version 这个地址获取到webSocketDebuggerUrl，也就是上边的address

const data = await axios
      .get('http://127.0.0.1:9222/json/version')
      .catch((err) => {
        this.logger.error(`未找到已启动的chrome浏览器1`);
      });

先获取webSocketDebuggerUrl，如果获取成功，使用puppeteer-core连接，如果获取失败，提示出来，不再执行。

slowMo可以控制脚本操作chrome的时候慢一些，方便观察。

自行登录

连接成功后，自己可以使用任意方式登录。

但是有一个很大的问题，启动后的命令行界面和浏览器，都不能关闭。不然登录状态就没了，再重新打开后又得登录一遍。如果爬取的大部分网站不需要登录还好，如果都要登录的话，那还是得想办法自动登录一下。

打码平台有很多，云码、超级鹰等都可以自己对接，不过大部分都是要钱的。也可以自己找找github上有没有开源项目，接入一下。或者等我找到之后，再来看我的😎

最小化窗口没有影响，跑起来还是会自己打开。

开始爬取

以下内容，和爬取热榜大同小异，有需要的自取。

获取css selector的方式也是用的上篇文章的方式。

// 等待数据展示区域展示出来
    await page.waitForSelector(
      '#juejin > div.view-container > main > div > div.minor-area > div > div.stat-block.block.shadow > div.block-body ',
    );
    // 等待头像加载出来, 头像出来了, 右侧信息肯定都有了
    await page.waitForSelector(
      '#juejin > div.view-container > main > div > div.major-area > div.user-info-block.block.shadow > div.avatar.jj-avatar > img',
    );
    // 文章被点赞数
    const articleUpvote = await page.$eval(
      '#juejin > div.view-container > main > div > div.minor-area > div > div.stat-block.block.shadow > div.block-body > div:nth-child(1) > span > span',
      (el) => el.textContent,
    );
    console.log(`文章被点赞数`, articleUpvote);
    // 文章被阅读数
    const articleViewNumber = await page.$eval(
      '#juejin > div.view-container > main > div > div.minor-area > div > div.stat-block.block.shadow > div.block-body > div:nth-child(2) > span > span',
      (el) => el.textContent,
    );
    console.log(`文章被阅读数`, articleViewNumber);
    // 文章被阅读数
    const articleJueNumber = await page.$eval(
      '#juejin > div.view-container > main > div > div.minor-area > div > div.stat-block.block.shadow > div.block-body > a > span > span',
      (el) => el.textContent,
    );
    console.log(`掘力值`, articleJueNumber);
    // 获取头像
    const avatarUrl = await page.$eval(
      '#juejin > div.view-container > main > div > div.major-area > div.user-info-block.block.shadow > div.avatar.jj-avatar > img',
      (el) => el.getAttribute('src'),
    );
    console.log(`头像地址`, avatarUrl);
    // 获取用户名
    const userName = await page.$eval(
      '#juejin > div.view-container > main > div > div.major-area > div.user-info-block.block.shadow > div.info-box.info-box > div.top > div.left > h1 > span',
      (el) => el.textContent,
    );
    console.log(`用户名`, userName);
    const position = await page.$eval(
      '#juejin > div.view-container > main > div > div.major-area > div.user-info-block.block.shadow > div.info-box.info-box > div.introduction > div.left > div.position > span > span:nth-child(1)',
      (el) => el.textContent,
    );
    console.log(`职位`, position);
    const company = await page.$eval(
      '#juejin > div.view-container > main > div > div.major-area > div.user-info-block.block.shadow > div.info-box.info-box > div.introduction > div.left > div.position > span > span:nth-child(3)',
      (el) => el.textContent,
    );
    console.log(`公司`, company);
    const intro = await page.$eval(
      '#juejin > div.view-container > main > div > div.major-area > div.user-info-block.block.shadow > div.info-box.info-box > div.introduction > div.left > div.intro > span',
      (el) => el.textContent,
    );
    console.log(`个人简介`, intro);
    let fansNumber = await page.$eval(
      '#juejin > div.view-container > main > div > div.minor-area > div > div.follow-block.block.shadow > a:nth-child(2) > div.item-count',
      (el) => el.textContent,
    );

信息拿到之后，重点是要干啥用。

信息处理

我提供几种思路，大家酌情考虑。

webhook通知

用nestjs里的定时任务，每天自动跑一下，拿到数据之后，用钉钉/飞书的webhook直接发出来，早上看看有无数据的变动或者消息。

数据趋势可视化

可以把每天的文章数据、粉丝数据、阅读量等记录一下，生成趋势图，看起来更直观一些。

也可以看到自己关注的博主最新更新的信息，计算一下他有几天没有更新了🤔

思路再打开一些，不一定是技术站点，其他任何自己感兴趣的网站都可以爬下来，做一些直观又好看的趋势图。

名片类可视化

可以把自己的数据，和平时自己看的动漫、电影、游戏等面板结合起来。

比如我能想到的就是JOJO的面板，搜了一圈，目前还没啥可用的网站。

由于游戏已经很久没玩了，从最开始的英雄联盟、守望先锋、PUBG后来就几乎不玩了，灵感已经枯竭。这两天帕兽大火，我才开了一下机，发现steam密码早忘了，然后账号密码找回，让我贴一张支付截图，我支付宝账单都找到17年去了🥲

小结

![[1-img-20241119141155.png]]

认知这个框的，估计也快30了吧😏

以上就是全部内容啦，没啥新鲜东西，有时间再慢慢做吧。

最近摸鱼环境不容乐观，闲里偷忙的机会越来越少啦！！

我是枣把儿，欢迎关注我的公众号：早早集市，来找我玩耍🥳

Nest从TypeORM到Prisma：迁移记录

Mon, 22 Jan 2024 00:00:00 GMT

最近把typeORM换成了prisma，主要是想用prisma的migrate功能，于是记录了一下其中发现的问题。

安装

全局安装prisma

npm i -g prisma

项目安装@prisma/client

pnpm add @prisma/client

在nest根目录初始化prisma，初始化后会在根目录创建一个prisma目录以及一个.env，目录里面有个schema.prisma 。

npx prisma init

nest创建一个新的模块prisma

nest g resource prisma

可以用@Global把这个模块注册成全局模块。

service部分可以参考nest官网的推荐或者其他野文，基本上都一样

@Injectable()
export class PrismaService
  extends PrismaClient
  implements OnApplicationBootstrap, OnApplicationShutdown
{
  constructor() {
    super();
  }
  async onApplicationBootstrap() {
    await this.$connect();
  }

  async onApplicationShutdown() {
    await this.$disconnect();
  }
}

把之前typeORM相关的，find、save等等方法一一替换成prisma。比如：

async findUserById(id: bigint) {
    return this.prisma.user.findUnique({
      where: {
        id,
      },
    });
  }

确定没有问题之后，看一下prisma的常用命令。这部分也可以先跳过，migrate dev命令放在了正确的迁移这一小节中。

db pull
基于数据库schema生成prisma schema

prisma generate
生成client代码，不会同步数据库

prisma db push
用于将本地的表结构改动同步到数据库。

如果表里已经有了字段和数据，再新增字段时，务必设置为允许为null的可选字段，如String?，否则会清空表结构。虽然会提示你，也不排除很多人会不看英文提示。

 username   String?  @db.VarChar(255) ✅
 username2  String  @db.VarChar(255)  ❌

如果是删除了字段。运行后会同步到mysql数据库中。同时不会删除已有的数据，只会删除对应的字段。

Prisma CLI reference 👈此处有所有命令，还是建议看看官方文档。

注意此操作不会像migrate一样会被记录

正确的迁移

迁移过程也有官方文档👈，这里相当于我实践后又讲述了一遍。

首先设置好开头init好的schema.prisma，如：

datasource db {
  provider = "mysql"
  url      = env("DATABASE_URL")
}

使用dotenv重新配置一下env文件，和项目现有的env文件结合起来，如：

npm install -g dotenv-cli

在package.json配置一下常用命令

  "migrate:dev": "npx dotenv -e .dev.env -- prisma migrate dev",
    "migrate:deploy": "npx dotenv -e .prod.env -- prisma migrate deploy",
    "prisma:generate:dev": "npx dotenv -e .dev.env -- prisma generate",
    "prisma:generate:prod": "npx dotenv -e .prod.env -- prisma generate",
    "db:push:dev": "npx dotenv -e .dev.env -- prisma db push",
    "db:push:prod": "npx dotenv -e .prod.env -- prisma db push",
    "db:pull:dev": "npx dotenv -e .dev.env -- prisma db pull",
    "db:pull:prod": "npx dotenv -e .prod.env -- prisma db pull",
    "db:seed:dev": "npx dotenv -e .dev.env -- prisma db seed",
    "db:seed:prod": "npx dotenv -e .prod.env -- prisma db seed",

然后把prisma默认的env里配置的DATABASE_URL挪到.dev.env 和 .prod.env里去，在不同环境测试一下能否正确连接数据库。

由于数据库里已有表结构和数据，prisma属于后来者，我不想丢失数据和结构，所以先使用db pull 生成prisma schema

pnpm db:pull:dev

最关键的一点来了。migrate dev会记录迁移的过程，如果直接使用migrate dev的话，他会清空数据，并生成一个migration和建表的sql，这样显然不符合预期。所以先手动创建一个migration

mkdir -p prisma/migrations/0_init

然后使用prisma migrate diff 输出一个sql脚本

npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql

此时，检查一下生成sql语句确保没有任何问题，然后把这个migration标记为已应用

npx prisma migrate resolve --applied 0_init

这个时候，去修改prisma schema后再使用migrate dev，就会生成基于已有数据库后的一个变更了。这个变更就不会影响已有数据了。

下边我也基于migrate dev的操作做了一些场景重现，感兴趣的可以瞅瞅。

migrate dev 操作演示

假设我不懂如何在两个环境之间迁移，只是在本地把玩prisma，直到我开始想到和线上数据库要同步一下。

运行pnpm migrate:dev会在prisma目录下生成一个migrations目录，并生成本次操作的sql。

现在本地数据库已经有了一堆表，刚刚接入了prisma，或者本地乱搞的时候已经不知道是什么状态了。我通过init后用db puill 生成了prisma schame 然后我在prisma schema中删除了一个model。

删除表

然后运行pnpm migrate:dev 并在提示下命名为delete_table1。它会提示你的数据库架构与迁移历史不一致，然后继续执行。因为此时我本地的状态已经混乱，migrations记录已经不在了，所以他从头开始给我记录了。

Drift detected: Your database schema is not in sync with your migration history.
The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.
It should be understood as the set of changes to get from the expected schema to the actual schema.

此时可以看到目录下生成对应的sql，里面是一堆创建表的SQL语句。再去本地数据库看的时候，数据都被清除了，并且自动执行了seed.ts 插入了假数据

然后再删除一张表admin_user，然后再运行一下migrate:dev，这次命名为delete_table2，可以看到这次没有提示错误，只是单纯的删除了一张表

DROP TABLE `admin_user`;

增加表

这个没有什么可说的

CREATE TABLE `color2` (
    `id` INTEGER NOT NULL AUTO_INCREMENT,
    `desc` VARCHAR(20) NULL,
    `desc2` VARCHAR(20) NULL,
    `desc3` VARCHAR(20) NULL,
    `value` VARCHAR(255) NOT NULL,
    `createTime` DATETIME(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
    `updateTime` DATETIME(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
    `userId` BIGINT NOT NULL,

    PRIMARY KEY (`id`)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

删除字段

然后我找了一张表color，给他直接加了一条数据，然后在model里把其中一个字段desc删掉，再去运行pnpm migrate:dev，这次生成的SQL里也只是删除了一个字段，对数据没有影响。

ALTER TABLE `color` DROP COLUMN `desc`;

增加字段

还是这张表color，再加两个必填字段desc、desc2

desc       String   @db.VarChar(20)
desc2      String   @db.VarChar(20)

因为这俩字段都是必填的，所以直接把表清空了，这次也没提示会清空表（？）。

再去数据造一条数据，然后再把这俩字段改成可选，再次执行pnpm migrate:dev

desc       String?   @db.VarChar(20)
desc2      String?   @db.VarChar(20)

这次没有数据没有被清，只是字段被设置了可以为null

-- AlterTable
ALTER TABLE `color` MODIFY `desc` VARCHAR(20) NULL,
    MODIFY `desc2` VARCHAR(20) NULL;

直接添加一个可选字段desc3，这次只是单纯增加了一个可以为null的desc3字段

-- AlterTable
ALTER TABLE `color` ADD COLUMN `desc3` VARCHAR(20) NULL;

正常情况下，已经有数据的表，不可能再增加一个必填字段了，因为已有字段就都不符合条件了。我这里只是演示一下，对于一个没接触过后端和数据库的前端来说，这个可能也是需要考虑的......

同步到其他环境的数据库

如果本地有docker容器的端口会冲突的话，先stop一下，然后把nest项目本地用docker-compose跑起来。

如何使用docker-compose 部署nest项目可以看下我这篇文章，里面有详细解释 👉使用 Docker Compose 部署 Nest 应用。

docker-compose up --build -d

打包完成后，来到nest服务内部，这里我用的Docker Desktop 演示。此时，正式数据库还是没有color2这个表，color表里也没有desc2 和desc的。然后运行一下，为了保证他运行不报错，我先把20240117080859_delete_table1删了，因为这个sql里全是建表的语句。后面会重新来一下这个过程来弥补这个错误。

/app # pnpm migrate:deploy

> master@0.0.1 migrate:deploy /app
> npx dotenv -e .prod.env -- prisma migrate deploy

Prisma schema loaded from prisma/schema.prisma
Datasource "db": MySQL database "zzstudio" at "zz_mysql:3306"

6 migrations found in prisma/migrations

Applying migration `20240117080859_delete_table2`
Applying migration `20240117082030_delete_field1`
Applying migration `20240117082351_add_desc2`
Applying migration `20240117082752_optional1`
Applying migration `20240117083056_add_desc3`
Applying migration `20240117083359_addtablecolor2`

The following migrations have been applied:

migrations/
  └─ 20240117080859_delete_table2/
    └─ migration.sql
  └─ 20240117082030_delete_field1/
    └─ migration.sql
  └─ 20240117082351_add_desc2/
    └─ migration.sql
  └─ 20240117082752_optional1/
    └─ migration.sql
  └─ 20240117083056_add_desc3/
    └─ migration.sql
  └─ 20240117083359_addtablecolor2/
    └─ migration.sql
      
All migrations have been successfully applied.

虽然我在本地开发时，先增加了两个必填字段desc、desc2，导致了当时数据被删除，后面又增加了desc、desc2、desc3三个可选字段，在正式环境的数据库中，数据并没有丢失，这三个可选字段也被加上了。为了验证修改也有数据的字段会不会产生影响，我把正式库和本地库的desc、desc2、desc3三个可选字段都造上数据，然后再去代码里把desc3改为desc4。

SQL如下

ALTER TABLE `color` DROP COLUMN `desc3`,
    ADD COLUMN `desc4` VARCHAR(20) NULL;

然后再模拟一下部署上线，再次运行deploy。

然后在正式环境运行deploy没有问题。但在本地执行上边那一步时，会检查我的migration记录，导致我跑不起来，所以我在不知道如何操作的情况下，只能又从垃圾桶里把删除的文件还原。

然后把全部migrations部署到正式上去运行deploy时，也会提示我

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 20240117075835_delete_table1

根据提示的地址，然后运行了，

/app # npx dotenv -e .prod.env -- prisma migrate resolve --rolled-back "20240117075835_delete_table1"

提示如下。把20240117075835_delete_table1这条记录回滚了。

Migration 20240117075835_delete_table1 marked as rolled back.

再次deploy时，因为20240117075835_delete_table1的sql里和正式数据库有冲突（重复创建了表），所以还是报错了。然后我就把20240117075835_delete_table1删了再重新部署上去deplpy，此时提示，这个migrate在之前的一个时刻失败了。因为prisma有一个自己表，会记录整个迁移的过程。

The `20240117075835_delete_table1` migration started at 2024-01-17 09:13:27.542 UTC failed

于是我又重新运行了一下resolve

/app # npx dotenv -e .prod.env -- prisma migrate resolve --rolled-back "20240117075835_delete_table1"

然后再次deploy，可以了。刷新了一下表里数据，desc3被删了，desc4也加上了。

开始修复

但是由于一顿操作，搞的两边的prisma migrations不太同步了，具体哪里不一样我也忘了。而我只想跳过第一步会给我清空表数据再重新建表的migration。

于是我把本地reset一下，把migrations全删掉，也不管他是啥状态了，先按照正确的迁移的做法建好一个0_init，标记为applied，然后继续修改一些model字段，然后再使用migrate dev生成了一条migration记录。重新“部署上线”

docker-compose up --build -d

在docker内部尝试一下deploy

/app # pnpm migrate:deploy

会报错：

A migration failed to apply. New migrations cannot be applied before the error is recovered from. Read more about how to resolve migration issues in a production database: https://pris.ly/d/migrate-resolve

Migration name: 0_init

Database error code: 1050

这个错已经在本地看了无数遍了。好解决！把它标记为已应用

/app # npx dotenv -e .prod.env -- prisma migrate resolve --applied 0_init

成功后再次使用deploy。可以看到没问题了，只执行了0_init之后的两个migration记录。

附录

Troubleshooting 包含了各种migration的操作
Prisma CLI reference 包含所有prisma cli 命令
Add to existing project 将prisma添加到现有项目中

小结

以上就是从typeorm到prisma的变更过程及遇到的问题。

如果对你有帮助的话，希望可以点个关注支持一下 (๑•̀ㅂ•́)و✧

Nest搭建：一个产品要有一个“好底子”：Nest项目搭建

Nest部署：使用 Docker Compose 部署 Nest 应用

当一个程序员开始做了一款产品

Thu, 28 Dec 2023 00:00:00 GMT

引言

从23.12.11开始下手去做产品和写文章，到现在不到一个月的时间，现在到了第一篇文章立下的flag -- 总结篇了👏。

方向

从写第一篇文章开始，我给自己立的目标是周更两篇。现在是第四周，除了每周更的时间不太固定，还算在正常更新。因为写的不是水文，不是流水账，也不是广告文，所以平时需要大量的时间去推进自己的产品，去推进自己的学习进度，以便能输出不那么水的文章。倒不是说要教会谁学前端，去炫技，更多的是还是记录真实的自己。因为24年的我在技术方面的追求上和17年刚开始工作的我没有什么大的区别，依然热爱和相信技术。

准备写文章和做产品，有两个核心的原因：

刻意训练写作能力，增强表达欲。
继续锤炼自己的技术。

第一点算是被时代的发展和自身的发展同时推动的，不管以后要发展视频、文字、技术，都离不开写作能力。自己能会做，和能讲出来是两回事，和讲和能写又是两回事，所以写作能力还是比较重要的。而且在写技术文章的时候需要查阅大量文档来确保准确性，对技术也是一种反哺。

第二点是我把技术当做终生爱好来看。所以我把技术和工作分开看待，生活需要钱，现在只有工作能满足搞钱的量和稳定性，而且大概率以后也是要靠工作，所以只要是在工作时间内，什么改需求这那的，我都毫无感觉。而且我时不时会想用什么工具链能提升一下工作的效率，挤出一些时间来，如果公司明显支持不起来，那就算了。所以有技术上的提升带来的一些自信，我对换工作没有太多的焦虑，实在不行就降降薪嘛~ 作为一个爱好，要么是真的是好玩爱玩，要么就是要能持续的提供正反馈。技术明显是属于后者，所以就慢慢有了整理的念头。

下场

于是23年7月、8月左右，开始思考如何把脑子中的想法构思一个个完整的产品，然后又演变成了如何把这一个个的产品串起来。8月底左右，有了一个大体的结构，我把生活抽象成了一个“集市”，单个产品抽象成了“摊位”，因为所有产品都是从我的生活或者我周围人的生活中得到的灵感，所有他们在一定程度上可以打通。我把产品大体分成了两类，一类用于“陈列”，一类用于“服务”，类似工厂和门店的关系。

思路有了，开始下手做起来，开了好头之后，开始思考怎么用文章输出。这中间也加了不少大佬、群、星球，开始观察别人怎么操作，因为我是带着目标来学习，所以这个过程也确确实实学到了一些东西，也花钱买了一些小册帮助自己入门，然后开始在公众号、掘金这种平台去发一些文章试试水。

于是就有了第一篇文章☝️：当一个程序员突然想做一款产品。

当然发第一篇文章之前我也在纠结以什么口吻，用什么类型的文字去写，然后就按两种风格写出来给老婆看了看，pass掉了那个读起来像是高高在上教育别人的那一篇。还没有任何经验的情况下这种议论文很难准确表达出来，还是得从叙事的角度开始写起。

第一篇的文章的正反馈很足，我在没有任何推广的情况下，发在了公众号和掘金，第一周内公众号的阅读量达到了1w，掘金大概2k~3k，导致我第一周过于兴奋，半夜要是突然醒来，就彻底睡不着了，脑子在疯狂的转，时不时看手机，阅读数有没有涨，有没有新的朋友关注🥲。不过到了第二周随着热度下降，也逐渐回归理智，不再过度关注这些数据，而是思考如何分配可支配时间。

时间

在写作上分配太多时间的话，产品和学习进度就会落下，会导致写不出有用的东西。倒也不是非要写出多么有用的东西，而且写的时候感觉状态不好，不顺畅，一旦有这种心理，我大概率会选择不写。

所以我考虑将50%的时间用于开发产品，15%的时间的用于输出文章，35%的时间用于学习。

至于一个人一天有多少可支配时间，很难说。要看工作忙不忙，家里事多不多。8月初我刚升级当了爸爸，现在孩子还没满6个月，家里的时间还需要不断磨合出来。家庭是要比其他的方面更需要时间打磨的，需要用心经营。所以在公司一般我都是选择“提效”的方式来提升自己的时薪，由于我的时薪增加，身价在涨，公司竟然也不肯为我多付钱，所以我把多出来的时间当成自己的可支配时间，很合理😎。

写作的风格或者能力也是做产品一样，光在脑子里想，很美好，下场去做，全是问题。能力就是在解决问题中提升的，尝试新的领域，解决新的问题，也会让我很兴奋。

图腾

头像和游戏ID、网名一样，是一个图腾，是一个代号。需要给人留下一点印象，这意味着不能太复杂，也不能太肤浅。

这确实是一个值得花时间去思考的东西，但这是放在更高的视角来说的，着眼于现状就是不能花太多时间在细枝末节上。这是我在花了时间去想，去画之后，也没得到一个好头像之后的结论。

因为我最开始希望有个头像去代表某种精神内核，但实际上是有了精神内核之后才赋予了头像意义。产品有意义，有用，有了“经济基础”，才有了头像这个本身没有意义，却因为产品有了“基础”之后才被赋予的“意识形态”。

不过没有关系，知识就是有这个好处：不管你是几年前就懂了，还是昨天刚懂，只要在今天能给别人说出来就行。

我以头像为切入点，开始输出一些文章，于是就有了这些文章：

前端搭建： Vue3项目实战：像素风LOGO编辑器 Pixeled Pic Pro
前端迭代（一）： iKun集合！Pixeled Pic Pro 前端迭代篇（一）
后端搭建：一个产品要有一个“好底子”：Nest项目搭建

当然这些文章明显是进入到细分的领域了，不那么宽泛，不能引起共鸣了，所以数据上只有第一篇文章的1%~2%左右，但不影响我的两个核心目标，数据只是附带的。

最开始这个产品我只想做生成头像、LOGO，但是随着我自己的使用，我发现它还可以大有可为：

可以当成自己的“物料站”，用来生产ICON、头像，而不用担心版权问题。
在玩了一天sketch之后，我发现有个叫颜色变量的东西，可以用在我的产品上，这样就会产生类似“掘金蓝”、“微信绿”的配色方案，再配合预设功能，可以衍生出一个负责陈列配色方案或者作品的“摊位”。两个摊位就可以产生联动。
因为底层基于Leafer 这个UI框架，我还可以抽离出来，做一个低端低代码平台，通过简单的拖拽，生成js、html、css，完成那种大国企客户需要做的那种大屏系统，你懂得，重复度又高，代码又原始。
也可以基于类似低代码平台的思路，做一个可视化的cli基建工具，配合一个模版仓库，实现快速启动另一个“摊位”
....

可以看出，产品的路线不是线性的，不是从开头开始的，而是不知道从哪里开始，又像一个网状一样，连带出很多优化点和其他产品。

自驱

把产品的蓝图画好之后，下一步就是如何一步步去实现了，因为是为爱发电，所以本身没有要求有多少回报。但是如果因为爱好正在做的事，恰好又能提供收益，那这就是最强的驱动力，但是太过依赖这种驱动力，一旦收益下降或者停止，这个心理上的落差也要提前考虑一下，所以我把预期放在最低，仅以学习为目的推动自己继续前进，定期复盘一下，如果什么都没学到，就调整节奏。

当然有一部分原因是我自己不是那种喜欢一直闲着的人，并且对技术有很强的好奇心。

以前也会时不时有，在公司就很焦虑，觉得公司不合适自己，不清楚要做什么的感觉。但放在7年这个时间维度上，感觉自己还是在分阶段的突破，虽然也会三天打鱼两天晒网，但是我三天打一次鱼，一直不停地打，也会比一直晒网的强了。只要是在公司没碰到的业务，我拿到自己的产品上来去实践和探索，感觉非常有意思，这算是我的源动力了。

大环境变差也会有推动作用，当然对有些人也会是反向推动。我不觉得躺平是不正常的事，我觉得不正常的是，你明明在躺平，但是你不认可自己的躺平行为，很拧巴。一边躺，一边又觉得别人学也对，也想使劲。为什么我会有这种体会？因为我也是个拧巴的人，我家里也天生带着拧巴的属性，所以我之前也在很长时间里陷入的思维的怪圈里。有时候可能不是想的太少了，而是想的太多，做的太少了，在实践中得到的“真知”太少，无法得到有力的回应。所以，停止思考，马上去做。

在哪个方面开始去做？我觉得都可以，虽然生活被分成了工作、学习、家庭、夫妻、子女、亲情等等很多方面，但是我发现你在任何一个方向用积极的心态去思考去做，都会带动其他方面变好。本来我以为生活像个木桶，要么提升长板（✅），要么弥补短板（❌），但是我现在觉得生活倒有点像是桶中桶，生活里的方方面面是一个大桶里的小桶，某个方面做的够好（加水），大桶里的水位也会跟着上涨。

玄乎，太玄乎了

所以，自驱，是一种心态，会影响你的方方面面。你要做的产品也许不能带来什么收入，但也是你心境的一种折射。

未来

虽说为爱发电，不求回报，但是有回报谁不要啊，是不是。立意抬得高点，至于人，那越俗越好。

为了保住自己的爱好，以后无论如何都要考虑增加收入这一点。那些买了房子的，还被出资人指指点点，约法三章的，你品一品，是不是这个道理。

本来是打算好好沉淀一年的，但是现在看来，还是越快越好，全力产出。毕竟七年就是一辈子嘛，现在看来，我这辈子的最后一年，要比前面六年产出都多，但是前六年哪些思考和行为影响到了今天，真的不好说，有可能就是前六年全部的所作所为成就了第七年。

所以，希望下辈子有更好的突破吧😅

写文章方面，分成几个方向写：

做了新东西，用了什么新技术，拿出来写一写，跟进一下进度
没有新东西，把别人写过的，自己不太了解的，去研究一下，再写一写
按系列写，不水文，写一阵子就总结复盘一下
穿插写一些生活、家庭感悟

收入方面，如果有了新的突破，也会写出来和大家分享一下！

ok，全文结束。

小结

从23.12.11写下第一篇文章，到今天的总结篇，算是完成了一个小闭环，成就感满满🥳，度过了新手期。

接下来就继续按照自己的节奏输出。

第一个小产品：像素厂Pixeled Pic Pro，也已经更新在了在线体验，现在纯前端已经开始限制功能的发展了，不日就会加入一些后端功能！

有任何问题或者兴趣也可以在公众号：早早集市找到我。

感谢你的阅读，我是枣把儿~

产品进度：像素风编辑器从Konva到Leafer

Thu, 28 Dec 2023 00:00:00 GMT

哈喽，大家好，我是枣把儿。

前两周我开发了一个像素风图片编辑器，正当我在逐渐完善功能的时候，我老婆过来看了看我做的功能。于是我在12x12的画板上给她画了两下，然后她说，你弄个120x120的给我看看，再写个字。结果我在生成14400个矩形的时候浏览器就卡死了😅，数值调小一些后，勉强可以生成出来，但是拖动和缩放都很卡，我尝试画了两下，断触也很严重，基本是不能用的状态。果然，一个真实的用户随便提的要求，都和自己构思的千差万别。

无奈之下，我又重新调研了一些框架，把核心功能从Konva换成了Leafer，Leafer是一个23年6月才发布1.0.0-beta的新框架，但是我使用起来感受还是比较丝滑的，他们自带的图形编辑器样式比起Konva也好不少（很多）

整体的设计也可以用分层的方式，分为ground（背景层）、tree（内容层）、sky（变化层）三层，当然也可以再自己添加自定义的层。

对SVG、动画等也支持，可以说再复刻一遍我的这个工具是没啥问题的（开源协议是MIT），而且还有node端可以使用。

然后就用Leafer把原来的功能都复刻了一遍

【此处的图丢了】

后面再加一下动态减少行和列，自己编辑的功能基本就差不多了。重构之余，我也有了如何自动生成像素图的一些新思路。

像素格子为10px的话，我导入一个图片为200x200，那我只需要把我的像素画板画成20x20，然后去图片里取色即可。取色也比较简单，依靠Canvas可以直接拿到rgba的色值，而且不用担心png的透明背景，或取了超出图片的颜色。

我先按一个10x10的区域只取一个点，也就是坐标(5,5)所在的像素点，把这个色值填充到像素画板对应的方格上。

按照这个思路，我实现了一下功能，再稍作调整后，我把自己的头像复刻了出来。

左侧是我导入的图片(297x297)，右侧是生成的像素画布(30x30)，每个方格是10x10，因为它本身就是像素图，所以正好可以检验我这个思路有没有问题。

还可以调小参数（5x5）后继续调试

可以看到，秋衣部分的比例更贴近原图了，但因为我取样次数（只取一次）太少，某些特征部分正好没卡在中间位置，就会有些怪异...

而且，5x5的时候是 3600个矩形块，在手动涂抹像素画布的时候，Leafer依然不卡。

转换操作用时88ms，这个我做了一点优化，本来是先把所有色值计算出来，然后去Leafer里用findOne 去找到对应的矩形块，然后填色。我改成了先把色值数组改成Map，然后findOne方法替换为children属性，用属性直接拿到所有子元素，避免循环查找，然后给每个子元素fill属性赋值成算出来的色值即可。

接下来肉眼可见的问题就是调整取样次数了，从一个格子里取一个点，改成按某种规律取多个点，然后判断一下该用哪个，这个还需要我去多多调试。

还有个问题就是图片风格化。我直接拿我的生活照去生成，看起来基本就是和打了马赛克一个原理。而像素化，我理解的应该是先提取图片的特征，特征里最主要的应该就是轮廓和五官，因为一个像素小人，怎么也得有鼻子有眼的，才能看着是一个小人。而有些线条类的图片，他的黑色或其他颜色的描边，对应到像素小人上就是一圈深色的色块把自己包围起来，就类似我上边的头像图片。

想到这里，我对我大学完全没有学高数感到很后悔，总觉得有个算法会直接解决我的问题，但我又不知道是什么，所以我只能先粗糙的实现这个“算法”，如果有大佬恰好看到，恰好知道的话，恳请评论区指点一下我orz。

想到上边，我脑子突然脑补到了我爸妈看到上边这句话，会对我说："你看我就说xxxx吧，当初不好好学，现在后悔了，你要是xxxx，你现在xxxx"。

我觉得我能产生这个想法，实在是太悲哀了，像巴浦洛夫的狗一样。我无法和自己的原生家庭倾诉，因为他们总是不去思考，只是习惯性的否定和消极。

同时，我在30岁的时候还能焕发起要远远大于22岁时候的技术热情，另一半的治愈效果可想而知。所以不要排斥谈恋爱、结婚，如果合适，这对你真的很有用，也许你排斥的只是双方原生家庭可能会隐隐带来的问题。

当然我现在说这些话相当的心平气和，因为我自己认知也在不断地突破，也有了自己的家庭，没有必要故步自封。让自己不断努力，也是争取让自己的孩子拥有更高的眼界，看事情看的更清晰。

ok，回到正题。接下来准备完善的两点：

增加取样频率，做成可配置的，观察一下最佳数量
看看自己能不能先风格化图片。
1. 思路就是，有多个色值都是属于红色，那就当成一种颜色处理。这样应该可以把鼻孔、眼睛区分出来
2. 深色做一下特殊处理，有些描边画出来的图，深色的优先级大于其他颜色，比如取色五个[ 黄，这黄，那黄，黑，白] 黑色权重高一些，因为这说不定是个眼睛

另外，个人网站支付这块我也做了一些调研，有一些第三方平台可以接入。等后续用到的话再来和大家汇报一下。

小结

这就是本篇文章的全部内容了，目前后端部分已经打通，也开发了一些接口，后续我准备快速把像素厂的前端迭代一下，按照正经的产品去发展！

从12.11准备周更2篇到现在是第3周，感觉技术文章受众确实是少一些。以后汇报产品进度的话，我就当闲聊来写了，和一些比较干的技术内容区分开。等到这个产品正式v1.0.0版本，我再来把整个流程的感悟做一下总结。

做产品还是走在写文章前面的，所以接下来我可能会调整一下节奏，把每天的可控时间再重新规划一下比重，产出效率再高一些，也会尝试用图文的形式去更新自己的进度~

有任何问题也可以在公众号：早早集市找到我。

感谢你的阅读，我是枣把儿~

使用 Docker Compose 部署 Nest 应用

Sun, 24 Dec 2023 00:00:00 GMT

引言

最近把像素厂（PixeledPicPro）的前端又翻新了一遍，也把 Nest应用部署到了云服务器，下面分享一下使用 docker-compose 的部署流程，保证你可以按步骤完成 Nest 项目（小水管服务器的）部署工作。

配置文件

本地和服务器是两个环境，所以难免会涉及配置文件问题，这里一并讲了。然后按本地模拟部署和服务器两部分演示

本地部署

首先保证你的 Nest 服务在本地 dev 环境下是正常可用的。有些同学不要一上来就拿不知道哪年的项目开始练手，结果项目本身就有问题。

因为本地和线上是两个不同环境，mysql、redis等很多需要区分环境的属性值都需要统一配置。Nest提供了@nest/config这个包，可以用来读取环境变量文件，并注入一个 service 到所有 module 里使用。

环境变量文件的类型有很多，可以是.env 文件，也可以是.yaml，也可以是.js, .ts。这里我使用的是.env，下面就以此为例。

.env 文件放在根目录下，如果你是有多个微服务，这个 .env文件默认读取的也是根目录。

在目录中位置如下：

在app.module.ts 中配置 ConfigModule，同样的，在这个文件中把 TypeOrmModule 的配置改成 env里的配置项

@Module({
	imports: [
		ConfigModule.forRoot({
	      isGlobal: true,
	      envFilePath:
	        process.env.NODE_ENVIRONMENT === 'production'
	          ? path.join(process.cwd(), '.prod.env')
	          : path.join(process.cwd(), '.dev.env'),
	    }),
		TypeOrmModule.forRootAsync({
	      imports: [ConfigModule],
	      useFactory(configService: ConfigService) {
	        return {
	          type: 'mysql',
	          host: configService.get('mysql_server_host'),
	          port: configService.get('mysql_server_port'),
	          username: configService.get('mysql_server_username'),
	          password: configService.get('mysql_server_password'),
	          database: configService.get('mysql_server_database'),
	          # 可以同步表结构，先开着
	          synchronize: true,
	          logging: true,
	          entities: [
	            你的 entities
	          ],
	          poolSize: 10,
	          connectorPackage: 'mysql2',
	          extra: {
	            authPlugin: 'sha256_password',
	          },
	        };
	      },
	      inject: [ConfigService],
	    }),
	]
})

redis配置同理，也把之前写死的属性值改成 env 文件里的配置项

redis.module.ts

@Module({
  controllers: [RedisController],
  providers: [
    RedisService,
    {
      provide: 'REDIS_CLIENT',
      async useFactory(configService: ConfigService) {
        console.log(`redis 打印`, configService.get('redis_server_port'));
        const client = createClient({
          socket: {
            host: configService.get('redis_server_host'),
            port: configService.get('redis_server_port'),
          },
          database: configService.get('redis_server_db'),
        });
        await client.connect();
        return client;
      },
      inject: [ConfigService],
    },
  ],
  imports: [],
  exports: [RedisService],
})

更改完成后，先启动一下本地服务，看看能不能正常访问，如果可以再进行下一步！这一步卡住也没事，慢慢 Google 一下，基本都是常见问题。出现问题再解决才能变成自己的东西。

本地开发的时候，我是用Docker Desktop单独跑了两个容器：mysql、redis。他们的 data 也挂载到了我本地目录上。而上线的时候我需要用 docker-compose 编排 nest、mysql、redis 他们三个，并且 nest 依赖于 mysql 和 redis，下面直接列一下我本地部署时的 docker-compose.yml。我直接把注释写在里面，免去上下滑动对比着看了

有些名称、端口我故意没有起成一样的，方便形成对比

version: '1.0'
services:
 # 我的nest服务名称
  nest-master:
	  # 指定了容器名， 这个容器名会用于容器间的通信， 比如你本地 mysql 的 host 是 localhost，那线上就用 zz_master 访问。 不声明的话就是‘nest-master’
    container_name: 'zz_master'
    # nest项目打包时，用的是他自己目录下的 Dockerfile
    build:
      context: ./
      dockerfile: ./apps/master/Dockerfile
    # 依赖于另外两个 service，另外两个 service 会先被构建
    depends_on:
      - zz-mysql-7
      - zz-redis-7
    # 端口映射，左边是宿主机上的端口 7008，也就是你打开浏览器http://localhost:7008 可以访问到 nest 的接口，而在容器内部他是运行在 7007 上
    ports:
      - '7008:7007'
    # 失败时重启，有时候 mysql 没启动起来，nest 已经完事了，就会连不上 mysql，所以一直重启，知道 mysql 启动成功
    # 不过你的项目如果有bug，他就会无限重启，所以要自己注意了
    restart: on-failure
    # 声明他们在zzstudio-server 这个网络中，可以用container_name进行访问
    # 不声明的话，也会在同一个网络中，名称默认是 项目_default， 比如我这个项目叫 zz-nest, 默认的网络名称就是 zz-nest_default
    networks:
      - zzstudio-server
  # 我的 mysql 服务的名称
  zz-mysql-7:
    # 我指定的容器名，当 nest服务（也就是上边的 nest-master）要访问 mysql 时，mysql的 host 就配置为 zz_mysql
    container_name: 'zz_mysql'
    image: mysql
    # 端口映射，当你从外部访问 3307 时会被映射到容器内部的 3306 上。
    # 因为这里我们三个服务在同一个网络下，所以我们prod.env 使用的应该是 3306
    ports:
      - '3307:3306'
    # 挂载的本地目录
    volumes:
      - /我的本地目录/mysql:/var/lib/mysql
      # 可以用于初始化时执行一些 sql，我查阅的野文里，有的用来解决数据库没有被创建，或用来表结构初始化，有需要的自行尝试
      # - ./init.sql/:/docker-entrypoint-initdb.d/init.sql

    # 相关的环境变量，密码应该是必须要设置的，忘了咋回事了
    environment:
      # 如果你的 mysql 是 8.x 不要指定 MYSQL_USER=root，会报错
      # 在指定了MYSQL_DATABASE后，会自动创建这个数据库！
      MYSQL_DATABASE: zzstudio 
      MYSQL_ROOT_PASSWORD: 123456
    # 同样，显式的声明在一个网络下
    networks:
      - zzstudio-server
  # 我的redis服务名称
  zz-redis-7:
    # 我指定的容器名称，当 nest 应用要连接 redis 时，redis server host 直接写这个‘zz_redis’ 即可
    container_name: 'zz_redis'
    image: redis
    # 端口映射，道理和 mysql 一样。可以看下上边的描述
    ports:
      - '6378:6379'
    volumes:
      - /我的本地目录/redis:/data
    networks:
      - zzstudio-server
# 声明网络，和上边所有的 server 下边的 networks 相对应
networks:
  zzstudio-server:
    driver: bridge

然后再对比看一下本地和线上的环境配置，我放在了一起演示，可以自己体会一下

redis_server_host=localhost #dev
redis_server_host=zz_redis #prod 对应 docker-compose.yml 里的 redis 的 container_name

redis_server_port=6379 #dev
redis_server_port=6379 #prod  ports 配的是 6378：6379，这里用的是 6379，因为他们已经在同一个网络里

redis_server_db=1

mysql_server_host=localhost # dev
mysql_server_host=zz_mysql # prod 对应 docker-compose.yml 里的 msyql 的 container_name
mysql_server_port=3307# dev 我本地 docker单独启用 mysql 时， 使用的 ports 是 3307:3306，所以我 nest 访问 mysql是用 3307 访问，从外部访问。同理 navicat 这种软件访问也需要从 3307
mysql_server_port=3306# prod 线上ports 配的也是 3307:3306，这里用的是 3306，因为他们已经在同一个网络里
#mysql_server_username=用户名
#mysql_server_password=密码
#mysql_server_database=数据库名称

nest 应用的 Dockerfile 如下，要注意的是我单独把 prod.env 复制进去了，不然不会扔进去。你也可以先自己试试，看看报错信息，思考一下是哪里出了问题，再回过头来按我这个流程排查。这样也能加深记忆。

这个 Dockfile 我也是参考了很多野文，这方面不再赘述了，能跑起来就行！

要注意：master 是我的服务的文件名，要记得换成自己的

FROM node:18.18.2-alpine3.18 as build-stage

WORKDIR /app

RUN npm install -g pnpm

COPY package.json .

RUN pnpm install

COPY . .

RUN pnpm build:master 

FROM node:18.18.2-alpine3.18 as production-stage 

COPY --from=build-stage /app/dist/apps /app/apps
COPY --from=build-stage /app/.prod.env /app/.prod.env
COPY --from=build-stage /app/package.json /app/package.json

WORKDIR /app

RUN npm install -g pnpm

ENV NODE_ENVIRONMENT=production

RUN pnpm install --production

CMD [ "node", "./apps/master/main.js" ]

EXPOSE 7007

写好了Dockerfile、 docker-compose.yml 和本地 env，我们先把本地当线上跑一下，跑之前先看看自己本地的docker 运行情况，不要冲突了。

docker-compose up

跑完后，出现下图，即为成功

如果出现了类似以下报错，可能是因为没建成数据库，也可能是你挂载的本地目录/你的目录/mysql不为空，导致初始化失败。

也可能会出现 178.x.x.x：端口号访问不到的报错，一般是你配置文件里 port 配错了，应该配成容器的 network 的 bridge 的 Gateway 地址

可以往上滑一下日志，看看具体报错信息，如有不知名报错，也可以在公众号：早早集市找到我，我再尝试复现一下。

zz_master  | Error: getaddrinfo EAI_AGAIN zz_mysql

然后我们拿浏览器测试一下 Get接口即可，能返回数据，终端里有输出日志就行啦

然后开始部署到云服务器！

服务器部署

往服务器部署前还需要改一下 docker-compose.yml

mysql、redis的 volumes 改为服务器上的地址，没有的话先新建一下

然后代码传到服务器上，可以用各种方式，如 git、ftp、jenkins等。

然后我们通过 ssh 连一下云服务器，然后进入到项目的根目录下，运行

docker-compose up

如果你的服务器上只安装了 docker 没有 docker-compose，可以使用以下命令先安装一下

sudo curl -L "https://github.com/docker/compose/releases/download/v2.6.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

sudo chmod +x /usr/local/bin/docker-compose

docker-compose --version

在经过几次 retry之后，可以看到服务成功启动!

zz_master  | [Nest] 1  - 12/24/2023, 12:32:59 PM   ERROR [TypeOrmModule] Unable to connect to the database. Retrying (4)...

使用 docker-compose down 停止，然后使用docker-compose up -d，在后台启动即可

然后使用docker ps ，查看已经在运行的容器～

docker-compose down 运行后也可以看到，启动的是三个 Container，一个 Network，Network 就是上边指定的网络

[+] Running 4/4
 ⠿ Container zz_master             Removed                                                                                                              10.4s
 ⠿ Container zz_redis              Removed                                                                                                                 0.4s
 ⠿ Container zz_mysql              Removed                                                                                                                 1.1s
 ⠿ Network server_zzstudio-server  Removed

ok，服务已经启动，接下来我用 Ngxin 做代理，把接口代理到 nest 服务上（容器的对外端口上）

nginx 也是一个 docker 单独启动的容器，目前用来挂载一个前端应用的目录，靠Termius的 SFTP 部署前端，因为Jenkins 太吃内存，后面我再调研一下有没有平替的方案。运维方面也不着急优化。

Nginx 转发到 Nest

一开始我是这样配置的

 location ^~ /api/ {
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_pass http://localhost:7007/; 
        }

在服务器里使用 curl 是可以调通Nest的接口的，但是用 Apifox 调不同，会报 502，查看错误日志

2023/12/24 08:04:24 [warn] 24#24: *4 upstream server temporarily disabled while connecting to upstream, client: xxxx, server: zzstudio.cn, request: "GET /api/user/aaa HTTP/1.1", upstream: "http://127.0.0.1:7007/user/aaa", host: "zzstudio.cn"
2023/12/24 08:04:25 [error] 24#24: *4 no live upstreams while connecting to upstream, client: xxx, server: zzstudio.cn, request: "GET /api/user/aaa HTTP/1.1", upstream: "http://localhost/user/aaa", host: "zzstudio.cn"

然后把配置里的 localhost 改成自己服务器的公网 ip，发现还是不行

然后又查看了一下 nginx 容器里的 ip

# 我的nginx容器名称叫nginx
docker inspect nginx

拉到最后，看到 Networks里，bridge 的 Gateway 地址，把上边 location 里的 proxy_pass 改成 http://Gateway 地址: 端口号/，再去 Apifox 尝试下自己的接口

 location ^~ /api/ {
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_pass http://Gateway 地址:7007/; 
        }

成功了👏

小结

以上就是我使用 docker-compose 部署 Nest 应用的全部过程，如果对你有帮助的话，还望点个关注、点赞支持一下～

也欢迎关注公众号：早早集市，第一时间围观我继续产出其他产品和文章～

感谢你的阅读，我是枣把儿~

后记 2023年12月26日17:59:16

nest项目通过docker-compose更新

# 先停止
docker-compose down 
# 然后后台启动的时候重新build，mysql和redis自动越过了，重新打包了nest服务
docker-compose up --build -d

sudo tee /etc/docker/daemon.json <<-EOF { "registry-mirrors": [ "https://1js6gccw.mirror.aliyuncs.com", "https://dockerproxy.com", "https://mirror.baidubce.com", "https://docker.m.daocloud.io", "https://docker.nju.edu.cn", "https://docker.mirrors.sjtug.sjtu.edu.cn" ] } EOF

sudo mkdir -p /etc/docker 
sudo tee /etc/docker/daemon.json <<-EOF 
{ "registry-mirrors": [ 
	"https://1js6gccw.mirror.aliyuncs.com",
	"https://dockerproxy.com", 
	"https://mirror.baidubce.com", 
	"https://docker.m.daocloud.io", 
	"https://docker.nju.edu.cn",
	"https://docker.mirrors.sjtug.sjtu.edu.cn" 
	] 
} 
EOF

sudo systemctl daemon-reload
sudo systemctl restart docker

docker run -d \
--init \
--name memoz \
--publish 5230:5230 \
--volume /home/memoz/:/var/opt/memos \
neosmemo/memos:0.22.3

iKun集合！Pixeled Pic Pro 前端迭代篇（一）

Thu, 14 Dec 2023 00:00:00 GMT

引言

上篇《Vue3项目实战：像素风LOGO编辑器 Pixeled Pic Pro》，我完成了V0.6.0版本，实现了基础功能。本来打算先写完后续的Nest篇、部署篇、总结篇，途中再自己默默更新到V1.0.0。但是写着写着，发现了些刺激的玩法，导致打乱了我的计划。

真是计划赶不上变化啊，无奈之下我决定加更一篇，来分享一下我又新加了什么有趣的功能！

功能一览

V0.7.0

自定义行x列生成

本来是v0.6.0的功能，偷懒了，放到了这个版本补上。

2. Toast组件

原因：Konva生成过多矩形后，页面会有明显卡段，所以需要一个提示组件，提醒一下用户。

基于daisyUI封装了一下Toast小组件，目前只支持同时显示一条消息，重复的消息会重复利用这个元素

Tab键切换颜色调整为空格键

因为Tab键和浏览器默认行为有冲突，页面有表单里元素，会自动focus，使用起来不太方便，所以调整为空格键了

V0.8.0

预设功能！

我在自己把玩自己的网站的时候，发现自己写死的几个颜色，有时候不够用，或者说我也不知道用什么颜色比较好。

于是我就想要不我用吸取颜色的软件，找几个高大上的图，吸几组配色，再放上去够大家选择。于是我寻思先在电脑里开始找几个图吧。

很突然，我就发现了iKun的图片（侵删），马上就来了兴致，先画个iKun玩玩再说！
画完了之后，导出，直接发到"回家吃饭"的群里！

果然啊，大家对我的绘画水平表示了强烈的认可。

我仔细对比一看啊，确实，除了背带略长，可以说是很还原了~

我又一寻思，这么好玩的功能，我发给别人，别人感兴趣了，他自己怎么再画出来呢？

他要去吸取颜色，目测一个格子的长宽数量，然后在网站上设置好，再开始画。显然是太麻烦了，没等开始画人就关闭网站了！

从这一点我想到了两个问题：

从吸取颜色到配置数量，太麻烦，太模糊。不像我这样擅长画画的话，很难一步到位
画着画着，格子不够了怎么办

于是我灵机一动，我把我现在的配置保存成一个“预设”，别人想用的时候我就发给他。

能用文本传播，很自然就能想到用json，而且用剪贴板的话，不懂代码的人也不必关心复制的是个什么玩意。用的时候再从一个入口粘贴进去，我这边自动给他加上，这样就完成了和上一个创作者相同的前置条件！

不擅长画画也是个好事，不光好的画受欢迎，只要你的画够抽象，相信喜欢的人也是非常多的。因为互联网的好处就是你可以从中找到任何奇怪爱好、奇怪角度的同行者。

为了解决第一个问题，我梳理了以下功能点，然后趁着热乎劲儿火速把他们实现：

预设的内容为：方格大小和数量配置，颜色组，名称

{
    name: "IKUN",
    cellConfig: {
      size: 5,
      border: 1,
      xCount: 15,
      yCount: 24,
    },
    // 从kunkun身上吸取的几个颜色
    colors: ["#564A54", "#DDDBED", "#1C1A25", "#DDB3C0", "#908B96", "#CC7A76", "#ffffff"]
}

可以一键导出自己的预设到剪贴板
粘贴板功能用的vue-use，搭建项目的时候已经内置好了

import { useClipboard } from "@vueuse/core";

const { isSupported, copy } = useClipboard();

3. 可以一键导入别人的模版

4. 选择预设后，会切换当前配置为预设内容

预设内容存在了LocalStorage，加载页面时会在本地缓存中加载预设，导入预设的时候，也会往本地缓存同步一下

// 加载本地预设
...
const localPresets = localStorage.getItem("ZZSTUDIO_PPP_PRESETS");
  if (localPresets) {
    try {
      const presets = JSON.parse(localPresets);
      // 检测合法性, 没问题的话, 直接应用
      if (presets.every((preset: any) => checkPreset(preset))) {
        // 去重, name一样会被去掉, 本地优先
        const newPresets = filterNoRepeatPresets(presets.concat(awsomePreset.value));
        awsomePreset.value = newPresets.concat();
      }
    } catch (err) {
      toast.value.show({
        msg: "本地预设加载失败",
        type: "error",
      });
      return false;
    }
  } else {
    logger.info("无本地预设");
  }
...
// 导出预设
... 
if (isSupported) {
    copy(copyPreset.value);
    toast.value.show({
      type: "success",
      msg: "已复制到剪切板!",
    });
  }
...

写完之后，开始测试，随手画几个蒙娜丽莎这种作品，发现了几个bug，马上修复。

由于点「导出图片」按钮次数太多，感觉有点迷瞪了，容易和「生成」按钮混了，于是我把「生成」按钮挪到了最上边，防止误触。

又导出了几张大作并且分享之后，有用户给我提出了建议：导出之后的边框太粗了，有点影响视觉。

我觉得很道理，安排！于是加了一个「导出去边框」的Toggle，测试了一下，确实是有内味了。

目前操作栏如下：

以上就是这两次小版本迭代新增的功能，边写边使用边改bug，闲里偷忙，只隔了一天就搞完啦~

作品演示

只复刻iKun肯定不是真粉丝，于是我把自己也打扮成了他的模样！

请把「优秀」打在评论区！！

小结

本次带来了两个小版本更新，以及我的传世之画作，希望大家喜欢！

从最初架构中，我并没有构思出这些功能或问题，而是在开发、使用的过程中，不断打磨、美化，发现问题，解决问题，从使用者的角度增加功能。可见，最重要的还是抛除杂念，然后下手去做。

而且！现在还只是纯前端功能，相信有了后端的加入，能够实现更多的有意思的功能~

看到这里，如果你已经提起了兴趣，可以去回顾我的上一篇《Vue3项目实战：像素风LOGO编辑器 Pixeled Pic Pro》，然后行动起来吧~

如果你对这个产品感兴趣或者有好的功能建议要告诉我，欢迎关注公众号：早早集市

感谢你的阅读，我是枣把儿~

🚀提升效率！早早下班！Sharp+Picgo实现压缩后上传并替换外链的命令行工具

Wed, 13 Dec 2023 00:00:00 GMT

引言

大家好啊，我是枣把儿！

最近写作比较多，而要发平台又好几个，插入图片的时候就很不方便。一开始我是白嫖掘金的图片地址，但是每个平台都会自动打个水印上去...

于是我又把之前写的命令行工具拿出来翻新了一些，加入了Sharp图片压缩、Picgo上传图床、markdown文件内容替换这三大内容，极大的改善了我的发文体验，并且感觉在日常中也比较实用。和大家分享一下~

功能一览

国际化文件翻译 - translate
1. 目前用于公司内部批量翻译国际化文件, 所以需要遵循一定的规则
2. 基于百度翻译, 需要自定义自己的appId和key
3. 支持指定单个文件翻译
4. 支持指定文件夹, 批量翻译所有文件
压缩文件 - tiny
1. 基于sharp, sharp支持的文件都可以压缩
2. 输出目录: 所有参数下, 压缩后文件都会输出到同级目录中
3. 输出时显示大小及压缩比例
  如: ✔ 190.4 KB => 115.2 KB (↓39.52%)【 demo1-zz-tiny-1702631665830.gif 】
4. 支持自定义名称输出 --name=xxx.png
5. 支持自定义压缩质量 --quality=70 (1-100)
6. 支持单个文件压缩 --file=xxx.png
7. 支持批量文件压缩
  - 指定文件夹 --dir=./demo (基于当前命令运行的目录)
    - 支持相对路径
    - 支持绝对路径
  - 指定文件名 --condition=abc
    - 模糊匹配所有包含abc且支持的文件类型都会被压缩
    - 如果没有指定--dir , 则--condition会在当前目录下查找
    - 模糊匹配到的内容, 会标红处理
  - 若批量压缩时, 指定了name(第四条), 则自定义名称后会自动拼接一个序号, 避免覆盖
8. 支持和picgo联动, 压缩完后直接上传到图床
  1. 需要先安装picgo, 启动, 并配置好图床配置
  2. 限制文件大小, 超过 max 的文件不会被上传
通过 Picgo 上传到图床 - picgo
1. 支持指定文件 -f 上传
2. 支持指定文件夹 -d 批量上传全部
3. 支持限制大小 -m 默认只上传60kb以内的图片
4. 支持模糊匹配 -co 文件名中含有co的图片, 且满足大小限制, 都会被上传
究极联动： tiny压缩 -> 自动传给picgo -> 自动把obsidian里的本地图片链接替换为上传后的url

安装

先安装sharp的两个前置依赖包。@img/sharp-darwin-arm64@0.33.0 、 @img/sharp-win32-x64@0.33.0

我的系统是macos M2，所以需要安装@img/sharp-darwin-arm64

npm i -g @img/sharp-darwin-arm64@0.33.0

windows10/11 (win32-x64)用户请安装 @img/sharp-win32-x64@0.33.0

 npm i -g @img/sharp-win32-x64@0.33.0

然后安装工具本体

npm i -g zzoffduty-cli@latest

运行 -h 看看是否成功

zz -h

tiny命令实现压缩

使用help命令查看所有支持的功能

zz tiny --help

  -f, --file <file>             要压缩的图片文件 (default: null)
  -d, --dir <dir>               压缩文件夹内所有文件 (default: null)
  -co, --condition <condition>  压缩文件夹内所有名称包含[--condition]的图片文件 (default: null)
  -q, --quality <quality>       压缩质量(1-100) (default: 75)
  -c, --colours <colours>       GIF色彩保留(2-256) (default: 128)
  -n, --name <name>             指定文件名输出 (default: "")
  -m, --max <max>               限制要上传的文件大小(kb)(仅当开启 --picgo 时会用到) (default: 50)
  --picgo [type]                调用picgo (无参数) (default: null)
  --no-picgo [type]             不调用picgo (无参数) (default: null)
  -h, --help                    display help for command

压缩功能演示：

picgo命令实现上传图床

PicGo在2.2.0版本开始内置了一个小型的服务器，用于接收来自其他应用的HTTP请求来上传图片。

默认监听地址： 127.0.0.1，默认监听端口：36677

以POST请求去上传

method: POST
url: http://127.0.0.1:36677/upload （此处以默认配置为例）
request body: {list: ['xxx.jpg']} 必须是JSON格式

返回的数据：

{
  "success": true, // or false
  "result": ["url"]
}

所以此功能通过Http请求的方式调用Picgo Server, 所以需要本地已经安装并启动Picgo, 并已经配置好了图床

如果使用picgo-core的话，手动配置json文件我觉得更痛苦一些。所以还是基于已经有了Picgo客户端的情况下，简化一些流程

使用help命令查看所有支持的功能

Options:
  -f, --file <file>             要上传的图片文件 (default: null)
  -d, --dir <dir>               上传文件夹内所有图片文件 (default: null)
  -co, --condition <condition>  上传文件夹内所有名称包含[--condition]的图片文件 (default: null)
  -m, --max <max>               大于指定大小(kb)的图片不会被上传 (default: 50)
  -h, --help                    display help for command

上传文件夹内所有大小符合限制的图片文件

上传所有名称中含有指定文字且大小符合限制的图片文件。没有匹配到会有提示

tiny 联动 picgo

在tiny命令后使用--picgo 开启压缩后调用picgo

压缩单个图片文件并通过picgo上传（这里也校验了max）

zz tiny -f ./demo/demo2.png --picgo

压缩文件夹内所有图片文件，并通过picgo上传所有符合大小限制的图片文件

zz tiny -d ./demo --picgo

压缩文件夹内名称含有指定文字的，且符合大小限制的图片，并通过picgo上传

zz tiny -d ./demo -co mo2 --picgo

压缩文件夹内名称含有指定文字的，且符合大小限制的图片，并指定输出的文件名，并通过picgo上传

ps: 因为名称含有指定文字这个指令是个批量操作，所以输出文件名必定会带一个后缀防止重复

zz tiny -d ./demo -co mo2 -n 自定义 --picgo

究极联动，一条龙服务

压缩 => 上传 => 自动替换markdown图片链接

./src/index.js tiny -d ./demo/md/配图 --picgo --replace -ref ./demo/md/demo4.md

此命令目前支持替换Obsidian里的Wiki链接，即 ![[demo2.png]]
如下图所示：

被压缩的图片里只要有demo2.png 就会替换成demo2.png压缩后的，上传到图床的url。
![[demo2.png]] 替换为 ![](http://www.baidu.com/demo2.png)

特别注意，有一些Obsidian配置的前置条件：

需要开启Wiki链接。因为目前版本我只实现了替换wiki链接对应的文本
Obsidian默认情况下，粘贴来的图片会显示成 paste img 2023123123.png 这种格式。所以建议安装 paste image rename 这个插件。原因是：

因为它名称自带空格，和命令行工具无法兼容！如果你批量上传过程中，有一个文件不符合大小限制，没有被上传，也没被替换。此时你想使用zz tiny -f ./paste img 2023123123.png -m 100 --picgo --repalce -ref ../xxx.md 继续放大限制，上传+替换时，文件就无法被解析了！
而且本身的名字比较长，不好找

以下是我的插件配置

当我截图后粘贴到md中时显示如下：

在粘贴图片时，文件存放路径配置：

在目录中展示为：

ok，以上就是我的obsidian配置，及我是如何使用zzoffduty-cli的全部内容！


zz tiny -d ./ -q 60 -m 100 --picgo --replace -ref ../🚀提升效率  ！早早下班！Sharp+Picgo实现压缩后上传并替换外链的命令行工具.md

✔ 正在压缩:.DS_Store
✖ 不支持此文件类型[.DS_Store]!
✔ 正在压缩:1-img.png
✔ 65.0 KB => 14.0 KB (↓78.42%)【 1-img-zz-tiny-1703041107406.png 】
✔ 正在压缩:2-img.png
✔ 423.4 KB => 95.9 KB (↓77.35%)【 2-img-zz-tiny-1703041107433.png 】
✔ 正在压缩:3-img.png
✔ 62.4 KB => 14.5 KB (↓76.76%)【 3-img-zz-tiny-1703041107602.png 】
✔ 正在压缩:4-img.png
✔ 88.1 KB => 17.9 KB (↓79.65%)【 4-img-zz-tiny-1703041107623.png 】
✔ 正在压缩:5-img.png
✔ 33.1 KB => 7.2 KB (↓78.23%)【 5-img-zz-tiny-1703041107660.png 】
✔ 正在压缩:img1.png
✔ 153.2 KB => 18.2 KB (↓88.14%)【 img1-zz-tiny-1703041107673.png 】
✔ 正在压缩:img10.png
✔ 100.1 KB => 37.9 KB (↓62.12%)【 img10-zz-tiny-1703041107703.png 】
✔ 正在压缩:img11.png
✔ 42.5 KB => 9.1 KB (↓78.61%)【 img11-zz-tiny-1703041107756.png 】
✔ 正在压缩:img2.png
✔ 139.4 KB => 32.2 KB (↓76.9%)【 img2-zz-tiny-1703041107779.png 】
✔ 正在压缩:img3.png
✔ 128.0 KB => 29.8 KB (↓76.75%)【 img3-zz-tiny-1703041107821.png 】
✔ 正在压缩:img4.png
✔ 79.1 KB => 17.5 KB (↓77.88%)【 img4-zz-tiny-1703041107867.png 】
✔ 正在压缩:img5.png
✔ 242.6 KB => 57.5 KB (↓76.31%)【 img5-zz-tiny-1703041107896.png 】
✔ 正在压缩:img6.png
✔ 94.7 KB => 21.3 KB (↓77.53%)【 img6-zz-tiny-1703041107974.png 】
✔ 正在压缩:img7.png
✔ 110.5 KB => 25.1 KB (↓77.31%)【 img7-zz-tiny-1703041108013.png 】
✔ 正在压缩:img8.png
✔ 110.6 KB => 24.4 KB (↓77.91%)【 img8-zz-tiny-1703041108058.png 】
✔ 正在压缩:img9.png
✔ 262.4 KB => 65.7 KB (↓74.98%)【 img9-zz-tiny-1703041108106.png 】
✔ 压缩成功 16 个
✔ 上传成功 16 个!
✔ 上传地址:
http://img.zzstudio.cn/1-img-zz-tiny-1703041107406.png
http://img.zzstudio.cn/2-img-zz-tiny-1703041107433.png
http://img.zzstudio.cn/3-img-zz-tiny-1703041107602.png
http://img.zzstudio.cn/4-img-zz-tiny-1703041107623.png
http://img.zzstudio.cn/5-img-zz-tiny-1703041107660.png
http://img.zzstudio.cn/img1-zz-tiny-1703041107673.png
http://img.zzstudio.cn/img10-zz-tiny-1703041107703.png
http://img.zzstudio.cn/img11-zz-tiny-1703041107756.png
http://img.zzstudio.cn/img2-zz-tiny-1703041107779.png
http://img.zzstudio.cn/img3-zz-tiny-1703041107821.png
http://img.zzstudio.cn/img4-zz-tiny-1703041107867.png
http://img.zzstudio.cn/img5-zz-tiny-1703041107896.png
http://img.zzstudio.cn/img6-zz-tiny-1703041107974.png
http://img.zzstudio.cn/img7-zz-tiny-1703041108013.png
http://img.zzstudio.cn/img8-zz-tiny-1703041108058.png
http://img.zzstudio.cn/img9-zz-tiny-1703041108106.png
✔ [🚀提升效率！早早下班！Sharp+Picgo实现压缩后上传并替换外链的命令行工具.md]图片链接替换完成!请前往检查!

然后直接复制，粘贴到各大平台即可！

使用前请仔细阅读readme.md，及最后的免责声明（害怕）

这次上传的图片太多，真的怕七牛云空间不够了。。

下一步计划

提高兼容性！

准备把文本替换功能抽离出来，现在只是满足了自己的需求。
可以再加一个掘金文章里用的图片缩放功能，或者自定义replace函数、正则表达式等。
收集更多其他人日常使用方式，融合进来

小结

这是一个我在为了简化日常工作和生活中一些复杂的、繁琐的、可联动的操作而开发的命令行工具，是一个纯粹为了效率的实用工具。

后续随着我自己的使用或其他人的反馈，我会加入更多的功能把它一步步的完善。同时一些适合可视化操作的功能，也会拆成web、客户端、小程序等形态，都是我的"预备摊位"！！

如果你对这个产品感兴趣或者有好的功能建议要告诉我，代码在Github，也欢迎关注公众号：早早集市

感谢你的阅读，我是枣把儿~

一个产品要有一个“好底子”：Nest项目搭建

Wed, 13 Dec 2023 00:00:00 GMT

大家好，我是枣把儿。

上周搞了一个前端小项目：Pixeled Pic Pro，是一个用来制作像素风格LOGO的Canvas编辑器。

同样，它的后端也是本着能用就行，先把功能搞出来的原则。我来分享一下后端实现过程以及发生的故事~

“底子”

我一开始要做的项目起名叫：早早集市。这是一个从不知道什么时候到23年8月份左右完成构思，在方向上开始清晰起来（当时是这么认为的）的项目。

原因就是，平时脑子里想法太多，多到必须下来，越写越多之后，我就在想怎么把他们搞出来，并且搞的有点联系。

然后再去了几次夜市吃喝之后，我就有了点灵感：我要不整个电子集市吧！

和大家去赶大集一样，每个产品相当于一个摊位，可以在一个入口里，看到所有在营业的"摊位"，并且像大集里的摊主一样，每个产品也是在向互联网用户提供服务或商品。

我仔细想想之后啊，感觉真不错。摊位五花八门，没有限制，我的想法也是天马行空，指不定想做什么，可以取悦自己；有的摊位提供“商品”；有的摊位提供“服务”；还有的摊位给别的摊位提供商品，个体也可以直接去他那“进货”。

打通了自己的想法之后，就越想越顺，也越想越复杂。生怕架构层面无法满足自己的设想。

搜索了很久微服务架构相关文章，问了下前同事（Java、运维）相关的思路（你问我为什么不问现同事？也问了，大部分表示就是用Spring全家桶，也知道微服务，也知道消息队列，也知道k8s。问怎么实现的、怎么设计的。不知道），最后也是给自己泼了泼冷水。

算了，不整那么复杂了，本来搞个项目，也是为了万一35岁以后真不干前端了，给自己留点"互联网遗产"，证明自己来过。别还没开始就给自己折腾"死了"。

冷却下来之后，我还发现，这玩意搞好了是个集市，搞不好不就是个工具站吗，网上一搜一大堆！

你看，果然还是打退堂鼓的时候思路更清晰一些。

但好在这次的构思过程足够深入，冷静下来之后还是让我感觉值得做下去，所以还是继续开始了这个故事。

所以，Pixeled Pic Pro 也是其中一个“摊位”，摊主(名字待定)提供的正是“服务”。

听完了故事，那就一起开始摆摊吧。

新建Nest项目

nest提供了 @nestjs/cli 这个包，先来安装一下

npm i -g @nestjs/cli

已经安装完了的话，可以升级一下

npm update -g @nestjs/cli

安装完成之后可以使用 ==nest -h== 查看有哪些命令，后续会经常用到

其中 ==--no-spec== 可以指定不生成测试文件，后面会用到

这里我把服务分为两个，一个gateway服务，用来对外实现api接口及鉴权。一个主服务，实现所有业务。除非不能满足业务，否则不再拆分。

PS: 拆出gateway只是为了在实际业务中感受它的好处和坏处，大家自行甄别、自由选择

开始创建项目！

nest new 项目名

选择pnpm后等待安装完成，完成后已经可以运行，进入项目根目录

pnpm start:dev

打开网站localhost:3000，可以看到Hello World！字样

因为我这里需要有另一个网关服务，所以我再新建一个app，通过monorepo的方式管理

# generator 可以缩写为 g
nest g app gateway

此时可以看到app gateway 已经被创建，同时自动创建了一个apps文件夹，里面包含两个app

安装微服务需要的包：

# add会安装在dependencies  加参数 -D 会安装在 devDependencies
pnpm add @nestjs/microservices

然后改造一下server部分，因为gateway在前，server在后，所以server需要改成微服务，通过TCP和gateway通信

const app = await NestFactory.createMicroservice<MicroserviceOptions>(
    AppModule,
    {
      transport: Transport.TCP,
      options: {
        port: 7577,
      },
    },
  );
  await app.listen();

然后在app.controller.ts里改一下接口，一会用来测试一下

@MessagePattern('hello')
  getHello(): string {
    return 'hello by zzstudio-server';
  }

来到gateway这边， gateway.module.ts里同样也要注册一下微服务，端口号和上面对应起来

@Module({
  imports: [
    ClientsModule.register([
      {
        name: 'ZZSTUDIO_SERVER',
        transport: Transport.TCP,
        options: {
          port: 7577,
        },
      },
    ]),
  ],
  controllers: [GatewayController],
  providers: [GatewayService],
})

然后在gateway.controller.ts里也写个方法测试一下
对了，先用@Inject注入刚才注册的。可以看到有个ts报错，我们回到server那边

@Controller()
export class GatewayController {
  @Inject('ZZSTUDIO_SERVER')
  private serverClient: ClientProxy;
  constructor(private readonly gatewayService: GatewayService) {}

  @Get()
  getHello(): string {
    return this.gatewayService.getHello();
  }

  @Get('app')
  getServerHello(): unknown {
    return this.serverClient.send('hello', 'hello');
  }
}

把两个项目跑起来测试一下，因为我们用的zzstudio-server新建的项目，所以跑dev默认启动的是zzstudio-server。

pnpm start:dev
pnpm start:dev gateway

然后浏览器输入localhost:3000/app，可以看到hello by zzstudio-server，通了。

然后再试试打包

# 这会打包zzstuido-server服务
pnpm build

# 这会打包gateway服务
pnpm build gateway

打包完成后，可以看到dist里分别产生了各自服务的文件夹

功能梳理

还是按照以前的习惯，做事之前先梳理和拆解，只要不影响核心功能，就放在下一个版本迭代。

也许会有一些同学奇怪，明明是自己的产品，为什么要和公司打工一样，还要搞版本，还要搞大纲，我在公司都没这么搞！

我是这样理解的：首先做产品的核心是==要把一个产品实现==，==过程有序，结果不遗漏==，就和你记账一样，如果你不记的很细致，你就无法总结到底哪些地方不该花钱。其次，你不能等有了用户，再重新完善文档，==因为你说不好是你的产品、还是你的故事、还是你的过程吸引了别人==。最后，这是自己的产品，是自己内心的==乌托邦==，你会本能的对它倾注更多的心血。

这样也能明白，为什么在公司打工为什么提不起劲儿来，因为它不是你的，也不是你感兴趣的，只是一个赚取收入的渠道。同时也可以知道，如果真的能把公司的产品，代入到自己的产品中，同时被公司领导们注意到，且不被自己的小领导窃取成果，且愿意推举给大领导，且老板也有正确的认知，公司也会因你而精彩（狗头保命）

说完了废话，开始正题。

首先gateway部分。

对外提供接口，可以起一个公共的前缀，比如/api/v1。
如果前端发生了改动，则去修改gateway里的请求逻辑，主服务不需要变
实现鉴权。jwt 双token，前端无感刷新，过滤掉没权限的请求。
如果主服务发生了改动，则去修改gateway里的请求逻辑，前端不需要变

接口目前很简单：

登录注册
1. 先用用户名密码+邮箱验证码注册
2. 后续再添加关注公众号注册之类的操作
导出功能
1. 次数统计看看有多少人使用了导出。相当于埋点了
2. 导出并压缩（这是一个不着急实现的公共功能，可以预见其他的产品也会有这个功能）
保存预设，json
保存图片，以一种字符串或者json的形式

其中3，4都不是必须的，先放一放。只要实现了框架结构和基本功能，后续按功能再加就很快了

功能实现

实现之前先用图来串一串思路。

用的Obsidian的Excalidraw画的

然后开始按照这个思路去实现功能，这里我只演示几个关键点。同样代码贴在文末，免费、开源

JWT模块注册

安装 @nestjs/jwt

pnpm add @nestjs/jwt

gateway.module.ts里注册

@Module({
  imports: [
    ClientsModule.register([
      {
        name: 'ZZSTUDIO_SERVER',
        transport: Transport.TCP,
        options: {
          port: 7577,
        },
      },
    ]),
    JwtModule.register({
        global: true,
        secret: 'zzdaddy',
        signOptions: {
          expiresIn: '1d',
        },
      }),
  ],
  controllers: [GatewayController],
  providers: [GatewayService],
})

自定义decorator

我想设置一个开关，标识哪个接口可以不需要登录就访问，没有这个标识的就都需要鉴权

先自定义一个装饰器，用于设置接口是否是公开的（true），没设置就是false

# 在gateway服务下，新建了一个custom文件夹，里面有一个custom.decorator.ts
nest g decorator custom --project=gateway

实现装饰器 custom.decorator.ts

export const setPublicRoute = () => SetMetadata('isPublicRoute', true);

自定义Guard

按照上图的思路，现在应该写一个Guard，用来控制权限

# 生成后自己改个名， 我改成了LoginGuard
nest g guard globalGuard --project=gateway --no-spec

然后在生成的guard里实现

canActivate(
    context: ExecutionContext,
  ): boolean | Promise<boolean> | Observable<boolean> {
    const request: Request = context.switchToHttp().getRequest();

    const isPublicRoute = this.reflector.getAllAndOverride('isPublicRoute', [
      context.getClass(),
      context.getHandler(),
    ]);
    if (isPublicRoute) {
      return true;
    }

    const authorization = request.headers.authorization;

    if (!authorization) {
      throw new UnauthorizedException('用户未登录');
    }

    try {
      const token = authorization.split(' ')[1];
      const data = this.jwtService.verify(token);
      // 这里会报没有user, 可以用declare module 给上边的 Request 在类型空间定义一下user
      request.user = data.user;
      return true;
    } catch (e) {
      throw new UnauthorizedException('token 失效，请重新登录');
    }
  }

guard要想生效，还要在gateway.module.ts里注册一下

 providers: [
    {
      provide: APP_GUARD,
      useClass: LoginGuard,
    },
    GatewayService,
  ],

此时注册完成后，再去浏览器请求一下 /app 接口，可以发现已经被拦截住了

{
  message: "用户未登录",
  error: "Unauthorized",
  statusCode: 401
}

自定义Filter

拦截住之后，问题就来了，貌似公司里Java接口，返回的都是内种的格式，我怎么自定义自己的返回格式
再回顾上图，实现一个过滤器，因为401是抛出了一个错误，会被filter捕捉到
再从custom里建一个filter吧，建完了把名字改改

nest g filter custom --project=gateway --no-spec

实现一下功能，因为他会捕捉所有错误，也就是你其他地方抛出来的不是HttpException的错误也会在这里捕捉到，所以要判断一下。

@Catch()
export class HttpCatchFilter implements ExceptionFilter {
  catch(exception: HttpException, host: ArgumentsHost) {
    const http = host.switchToHttp();
    const response = http.getResponse<Response>();

	// 我把自己代码写错导致的错误都返回500
    const statusCode =
      exception instanceof HttpException
        ? exception.getStatus()
        : HttpStatus.INTERNAL_SERVER_ERROR;
    // 使用exception的message 也可能是 exception.message.message 或 exception.message.error
    let message = exception.message;
    // 使用了参数校验之后，多个参数校验不通过，会返回一个数组，所以这里合并了一下，优化展示
    if (exception instanceof HttpException) {
      let res = exception.getResponse() as { message: string[] };
      message = res?.message?.join
        ? res?.message?.join(',')
        : exception.message;
    }
    // 这里json的格式、字段、内容，自己随便写
    response.status(statusCode).json({
      code: statusCode,
      message,
      error: 'Bad Request',
    });
  }
}

写完同样需要在gateway.module.ts里的providers下注册（其他全局注册方式建议自行查阅）

providers: [
    {
      provide: APP_GUARD,
      useClass: LoginGuard,
    },
    {
        provide: APP_FILTER,
        useClass: CommonErrorCatchFilter,
      },
    GatewayService,
  ],

再回到浏览器看一下/app接口, 在校验失败的情况下，返回结果已经变成了我们想要的结构

{
  code: 401,
  message: "用户未登录",
  error: "Bad Request"
}

然后再把刚才写的setPublicRoute给/app这个接口用一下

@Get('app')
@setPublicRoute()
getServerHello(): Observable<any> {
  return this.serverClient.send('hello', 'hello');
}

再去浏览器看一下，hello by zzstudio-server，这个内容又出来了。

写完了别忘了保存啊。我都忘了，还以为哪里写错了呢。

然后再实现一个post接口试试看

@Post('login')
@setPublicRoute()
login(): Observable<any> {
  return this.serverClient.send('login', { username: 1, password: 2 });
}

然后在我的主服务里，接受这个请求，然后返回俩token

@MessagePattern('login')
  login(): object {
    return {
      access_token: '123456',
      refresh_token: '123456',
    };
  }

然后再拿postman、postwoman、apifox去请求试一试，我用的apifox

可以看到，拿到了数据，但明显还不是我们想要的结构。

自定义interceptor

所以我们再回顾一下上图，可以在interceptor里去处理一下next.handle() 之后的数据
再回顾上图，实现一个拦截器
再从custom里建一个吧，建完了把名字改改

nest g interceptor custom --project=gateway --no-spec

实现一下功能

@Injectable()
export class HttpCommonInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const response = context.switchToHttp().getResponse<Response>();
    // 201时返回200
    if (response.statusCode === HttpStatus.CREATED)
      response.status(HttpStatus.OK);
    return next.handle().pipe(
      map((data) => {
        return {
          code: 200,
          data,
          message: 'ok',
        };
      }),
    );
  }
}

也需要在gateway.module.ts里注册一下

providers: [
    {
      provide: APP_GUARD,
      useClass: LoginGuard,
    },
    {
      provide: APP_INTERCEPTOR,
      useClass: HttpCommonInterceptor,
    },
    {
      provide: APP_FILTER,
      useClass: CommonErrorCatchFilter,
    },
    GatewayService,
  ],

然后再去apifox请求看一下

是我们想要的格式了。

权限校验部分

我新建一个auth模块，在里面实现login、refreshToken接口

nest g resource auth --project=gateway --no-spec

登录接口，返回两个token，给到前端之后，前端请求时需要在headers里携带access_token，当提示前端已过期时，前端再用refresh_token去请求refresh接口。refresh接口则会再返回两个新的token。以此达到无限续签。

@Post('login')
  async login(
    @Body() user: LoginDto,
    @Res({ passthrough: true }) res: Response,
  ): Promise<any> {
    let userInfo = await this.authService.login(user);
    if (userInfo) {
      const access_token = this.jwtService.sign(
        {
          user: {
           ...
          },
        },
        {
          expiresIn: '60m',
        },
      );
      const refresh_token = this.jwtService.sign(
        {
          userId: userInfo.id,
        },
        {
          expiresIn: '7d',
        },
      );

      res.setHeader('token', access_token);
      return {
        access_token,
        refresh_token,
      };
    }
  }

   @Get('refresh')
  async refresh(@Query() refreshParams: refreshDto) {
    try {
      const data = this.jwtService.verify(refreshParams.refreshToken);

      const user = await this.authService.findUserById(data.userId);

      const access_token = this.jwtService.sign(
        {
          ...
        },
        {
          expiresIn: '60m',
        },
      );

      const refresh_token = this.jwtService.sign(
        {
          userId: user.id,
        },
        {
          expiresIn: '7d',
        },
      );

      return {
        access_token,
        refresh_token,
      };
    } catch (e) {
      throw new UnauthorizedException('token 已失效，请重新登录');
    }
  }

使用typeorm链接mysql

pnpm add typeorm @nestjs/typeorm mysql2

在gateway.module.ts里注册。synchronize: true时 user表会自动创建。不过这里只是为了演示，实际上我是在主服务里维护的user模块

TypeOrmModule.forRootAsync({
      useFactory() {
        return {
          type: 'mysql',
          host: 'localhost',
          port: 3306,
          username: 'root',
          password: '123456',
          database: 'zzstudio',
          synchronize: true,
          logging: true,
          entities: [User],
          poolSize: 10,
          connectorPackage: 'mysql2',
          extra: {
            authPlugin: 'sha256_password',
          },
        };
      },
    }),

这样，实现了基本的接口之后，再配合上边写的自定义Guard，就可以实现对权限的校验了。细节部分，我就不展开了，对大家意义也不大。

本地开发的话，我是用的docker desktop，先跑一个mysql，这样感觉比较省事。后续上线的话，我用的是docker-compose，把服务+mysql+redis 一起编排上线

ok。结束

PS：后续更新的方向，将会按照故事的发展进行，但每一个系列我也会尽快收尾。

小结

这次分享了一下我最初构思的那个项目的大概背景和设定。以及从零搭建一个Nest项目，按照上边流程，搭建出来是没问题的。

因为我自己的服务早就写完了，这次我专门从头建了一个项目，又码了一遍，后面可能鉴权，token方面写的不太细致。因为感觉这种教程应该是一搜一大堆了，我再重新来一遍意义不大。

代码我还是会尽快放在Github中，作为v0.1.0版本，后续会把鉴权、日志、文件、邮箱、支付等等一些公共的模块会更新在这个仓库里，需要的同学可以pull下来，再自己改改，作为项目的启动模版。

当然，有任何问题也可以在公众号：早早集市 找到我。后面我会持续分享早早集市里的每一个“摊位”的诞生和迭代过程，但不构成对大家技术栈、代码规范、命名方式、架构层面合理性等等见仁见智的角度的任何建议。

大家就当听个故事，新手的话顺便还能入个门，半路进厂想做全栈的也可以参考一下我的思路，也欢迎来找我一起交流 ~

感谢阅读，我是枣把儿 ~

Vue3项目实战：像素风LOGO编辑器 Pixeled Pic Pro

Mon, 11 Dec 2023 00:00:00 GMT

引言

上篇文章《当一个程序员突然想做一款产品》说到，我在做自己的产品的过程中，萌生了自己做一个像素风LOGO编辑器的想法，并设计了产品的整体功能、技术栈选择、服务器部署全部流程。

出于一个开发人员本能的对产品排期的排斥，我非常想向身为产品的自己提出一点时间上的吐槽。

但是我很快就忍住了，因为我想到xw了更好的处理办法。

版本划分

产品的核心功能是：生成任意行和列的方格子，按自己的喜好进行涂抹上色，创作完自己想要的图片后，导出图片即可。

所以我把核心功能定为V1版本：

一个可拖动的画布，一个可绘制的区域，区域内由带或不带黑色边框的单元格组成，并且可缩放可拖动。
单元格的形态为正方形格子。可以设置数量，如：100x100，单个方格可以设置大小，如格尺寸为：5x5
操作模式分为两种： 1. 鼠标模式 2. 绘图模式
鼠标模式下，可以自由拖拽
绘图模式下，鼠标可在绘图区域的小方格上点击并滑动，小方格会被设置对应的颜色
1. 颜色可配置，并且方便切换：比如tab键自动轮换预制的几种颜色
绘制后，图片可导出

我打算这样制定版本号规则：x.y.z

z：通常在未上线阶段或上线后小范围迭代使用，如样式修改、代码优化等不涉及功能的改动后，此版本号加1。
y：通常为新增功能，bug修复等功能的迭代版本，如我这次开发的产品，我打算以v0.1.0开始，在每完成一个上述的独立功能123456后，此版本号加1，直到产品闭环。
x：通常为一个产品的稳定版本，此时产品的功能已经完成闭环，与上一个版本比，在功能、操作、逻辑上有重大更新或修复致命bug时，此版本号加1

这样，我就可以在有限的时间内推进项目的正常开发工作，让大家看到我这段时间的成果，后续还可以掏出时间来持续的迭代产品。显得有条不紊，尽显老鸟风范，皆大欢喜。

项目搭建

首先安装degit这个工具，它可以用来安装社区模版里的优秀模版，以此快速启动我们的项目

npm install -g degit

在社区模版里挑选过后，我选择了boot-vue。作者这样说：

⚡ 闪电般的速度：使用 Vue 3、Vite 和 pnpm 构建，速度飞快 🔥
💪 强类型：使用 TypeScript 💻
🔥 最新语法：使用新的 script setup 语法 🆕
📦 自动导入组件：自动导入组件 🚚
📥 自动导入 API：使用 unplugin-auto-import 直接导入 Composition API 和其他 API 📨
🎨 UnoCSS - 瞬间响应式 CSS 引擎，提供轻量级和快速的样式应用方式。
🌼 Daisy - 免费开源的 Tailwind CSS 组件库
💡 官方路由器：使用 Vue Router v4 🛣️
🎉 加载反馈：使用 NProgress 提供页面加载进度反馈 🔄
🍍 状态管理：使用 Pinia 进行状态管理 🗃️
📜 中文字体预设：包含中文字体预设 🇨🇳
🌍 国际化就绪：使用本地化准备好国际化 🌎
☁️ Netlify 就绪：可在 Netlify 上零配置部署 ☁️

可以看到，它的功能已经非常齐全，并且没有太多多余的业务类代码，拿来作为项目的启动模版是非常香的。

npx degit kirklin/boot-vue pixeled-pic-pro

可以看到一个叫pixeled-pic-pro的项目已经被创建，进入项目目录，开始安装依赖

# 没有安装pnpm的话，先自行安装一下
pnpm i

安装完成后，运行一下

pnpm dev

可以看到页面已经运行在了8888端口下，并且自动开启了一个__inspect的页面

打开浏览器，发现还有一个切换主题皮肤的功能（Daisy），可以尝试后选择一个比较严肃和正经的皮肤

为了以防开发完了才发现别人的库有打包的问题，我们可以先运行一下打包命令，看看是否正常

pnpm build

good，没有问题。

梳理项目结构

看看这个项目里的东西有没有需要删除或修改的地方

router

路由钩子里已经结合NProgress，做了加载的进度反馈，后续如果有其他需要结合路由来判断的状态，也会继续添加在这里。

模式是 Hash模式，是用createWebHashHistory()创建的，可以看到url上会有一个#标志。

如果使用createWebHistory()，则创建的是Html5模式，这种模式的url看起来会比较“正常”，但需要服务器做一些配置工作。

#nginx部分配置
location / {
  try_files $uri $uri/ /index.html;
}

store

通过pinia进行状态管理，已经有了一个小例子，后续使用的话可以仿照着改造一下。

pages

页面部分。它有两个页面。为了保持简单，我就只用这两个页面，一个写欢迎页，一个写功能页。标题栏也直接拿来用，不要浪费。

欢迎页比较简单，我准备放一个功能演示的GIF，配一个大大的按钮【开始创作】

把首页里左上角名称改成Pixeled Pic Pro和作者相关的Footer注释掉，github地址换成自己的。这部分内容在layouts里。

注意：此项目使用的是基于Tailwind CSS 的UI组件库 daisyUI，而Tailwind CSS是通过UnoCSS来控制引入的，所以开发时需要打开它们的文档，方便查阅。

此时页面长这个样子

再稍微调整一下样式，我先设置了一个flex布局，画布页面直接flex-1占满

layouts/index.vue

<template>
<div class="font-chinese antialiased">
	<div class="min-h-screen flex flex-col">
		<Navbar />
		<RouterView />
	</div>
	<!-- <Footer /> -->
</div>
</template>

画布页面StoreTest.vue初始状态如下，文件名字可以改一改，但是我不改

还需要一个操作栏，放置一些常用配置和功能

我选择把操作栏放在左侧，并且加入几个功能按钮：生成、导出、颜色配置等，按钮可以边写边加，先按主要功能一步一步的来实现。

设置到了这里，我发现了一个小问题，作者似乎对html使用了scrollbar-gutter：stable这个属性，导致我页面没有滚动条的情况下，在右侧也出现了gutter

于是乎我把这个属性覆盖了一下，一切就正常了起来~

src/styles/main.css

 html {
    	scrollbar-gutter: auto
    }

有内味儿了吧？接下来开始实现主体功能

画布相关功能

安装konva、axios(备用)依赖

pnpm i konva axios

结合之前多次头脑风暴的经验，canvas的可玩性是非常高的，可以实现很多有趣但可能没用的小工具，但这里重点是很多。

很多意味着重复，写代码最忌的就是无脑复制粘贴。

哪怕写代码时的思考逻辑不是最优的，写出来的代码也不是最“优雅”的，还是要保持基本的封装的潜意识。带着一种“如果别人使用我的组件、插件的时候，他们会不会觉得不方便”的想法去思考如何封装更合理。小到一个方法，大到一个组件，都是一样的道理。

但也没必要因为追求“最合理”，陷入到一种情绪负担上，你的大脑开始焦虑的时候，你可以提醒自己，做不好是正常的，所有人都会出现这样的问题，做错的过程也同样有用。就如同我现在这个产品一样，分版本迭代，逐步解决问题。

这里为了在避免后续迭代中产生其他页面，也用到画布的相关操作，我们把整个画布封装成一个类。

如果另一个新的产品也和画布有关，那我们可以进一步把他抽离，发布到npmjs上。就如同这个boot-vue的作者自己内置的@kirklin/logger、@kirklin/reset-css一样。

回到正题。

把这个类随便取一个名字：AppStage，Konva里已经有个Stage的概念了，所以我这里稍微改改。
回顾一下需要实现的功能，按照思路，罗列出AppStage要实现哪些方法：

初始化画布 initStage

export class AppStage {
	constructor(
		ref: Ref,
		options: AppStageConfig = {
			isAllowMouseSelectShapes: true,
			isInitKeyboardEvents: true,
			mouseMode: "basic",
			scale: false,
			scaleMember: null,
		}
	)
	...
	
	init(options: AppStageConfig) {
		console.log(`初始化容器为: ${this.canvasWindow.width} x ${this.canvasWindow.height}`
		);
		this.stage = new Konva.Stage({
			container: this.containerRef,
			width: this.canvasWindow.width,
			height: this.canvasWindow.height,
			id: "baseStage",
			draggable: options.scale
		});
	}
	...
}

设置是否可缩放 set
设置可缩放的对象 (macos上触摸板两指上下滑动等同于鼠标放大缩小)

// Konva的stage可以监听鼠标滚轮事件
this.stage.on("wheel", (e) => {
	// 通过wheelDelta判断，是在放大还是缩小
	if (evt.wheelDelta > 0) {
          // 放大
          if (this.scaleMember.scaleX() < max) {
            this.scaleMember.scaleX(this.scaleMember.scaleX() + step);
            this.scaleMember.scaleY(this.scaleMember.scaleY() + step);
            // this.scaleMember.move({ x: -offsetX, y: -offsetY }) // 跟随鼠标偏移位置
          }
        } else {
          // 缩小
          ...
})

绑定鼠标事件（落下、移动、抬起）（移动过程中，划过的元素进行填充颜色）

type MouseMode = "basic" | "draw" | "clip" | "fill";

解绑鼠标事件（有绑定就有解绑）
添加图形
批量添加图形（因为方格要被统一的缩放，并且只有方格可以交互，所以批量添加时需要加入到一个Group中, 方便管理）
设置鼠标模式（切换绘图、拖拽模式，类似ps、ai里的操作）

switchMouseMode(mouseMode: MouseMode) {
	this.mouseMode = mouseMode;
}

查找图形（比如查找没有上色的图形等功能可以用到）
导出图片（回到缩放前的状态，然后导出）

由于具体的业务代码对大家可能并无卵用，细节代码就不展开了，代码链接放在文末的小结中。

生成格子

由于生成12x12这个格子属于这个产品的业务功能，我这里没有选择把他放进类的方法里，选择在自己的组件里实现

单元格配置先给几个默认的预设，方便在不配置的情况下也能正常使用，视频里用Adobe AI来实现的时候使用了十二根线交错，所以我这里先默认给个12x12的方格布局。并且生成的单元格，默认是正方形，不排除后续加入三角形、圆形。所以我先留个口子。

const basicCellConfig = reactive({
	size: 5, // 单个格子宽高
	border: 1, // 边框宽度
	xCount: 12, // 横向有几个
	yCount: 12, // 纵向有几个
})

生成12x12单元格方法，这里我们先把所有rect生成好，然后传给AppStage类里按Group生成图形

const genPixelBoxCells = () => {
  let { x, y, strokeWidth: border } = PixelRect.value?.getAttrs()
  let cells = []
  for (let xIndex = 0; xIndex < basicCellConfig.xCount; xIndex++) {
    for (let yIndex = 0; yIndex < basicCellConfig.yCount; yIndex++) {
      let attrs = {
        x: x + border + basicCellConfig.size * xIndex,
        y: y + border + basicCellConfig.size * yIndex,
        width: basicCellConfig.size,
        height: basicCellConfig.size,
        strokeWidth: basicCellConfig.border,
        stroke: 'black',
        fill: 'white',
        name: `fillnode-${xIndex}-${yIndex}`,
        draggable: false,
      }
      let rect = new Konva.Rect(attrs)
      cells.push(rect)
    }
  }
  // 把所有格子放进一个组里，方便同时管理
  Stage.value.createShapesByGroup(PixelRectGroup.value, cells)
}

此时，页面如下：

鼠标模式、鼠标事件、键盘事件

监听鼠标事件，然后实现涂色功能，先默认一个颜色，把功能做出来，然后再实现切换颜色的功能

在AppStage.ts里实现监听和上色功能

listenAndFillRect() {
	// 监听前，需要设置一个绘图对象，涂色时只对这个对象有效
    if (!this.drawTaget) {
      console.error(`未设置绘图对象 drawTarget : this.drawTarget(target:any)`);
      return;
    }

    this.drawTaget.on("mousedown", (e: any) => {
    // 如果不是自己的模式，就不执行
	  if (this.mouseMode !== "fill") {
        this.drawTaget.off('mousedown')
        return;
      };
      // 绘图时禁止冒泡, 防止拖拽
      e.cancelBubble = true;
      this.fillStatus = "filling";
      e.target.fill(this.fillConfig?.color);

      this.drawTaget.on("mousemove", (e: any) => {
        if (this.fillStatus === "filling") {
          e.target.fill(this.fillConfig?.color);
        }
      });

      this.drawTaget.on("mouseup", () => {
        this.drawTaget.off("mousemove");
        this.drawTaget.off("mouseup");
        this.fillStatus = "done";
      });
    });
  }

在组件内实现切换模式功能，这个功能同样封装在AppStage里，两种模式切换的时候对应两套鼠标动作，所以还需要一个listenAndAssignTask功能，来switch case一下模式，对应不同的操作逻辑

const changeMode = () => {
  Stage.value.switchMouseMode(mode.value)
  Stage.value.listenAndAssignTask()
}

再加一个切换颜色的功能，写几个div，背景色就是配置的颜色，横向排列，因为我们这里是方格，所以展示颜色的div也显示成方格，如下图

这个切换颜色的小组件，还可以继续优化一下，做一个动画，点击了谁就跳到第一个位置上。这里先记下，后续再做，继续推进功能，避免中途加太多东西，导致延期。

鼠标一个一个的点，明显不方便，我再加一个tab键切换颜色的功能

StoreTest.vue

const bindKeyboardEvent = () => {
    window.addEventListener("keydown", (e) => {
      if (e.code === "Tab") {
        let index = colorConfig.value.findIndex(color => color === selectColor.value)
        index = index >= colorConfig.value.length - 1 ? 0 : index+1
        changeColor(colorConfig.value[index])
      }
      e.preventDefault();
    });
}

目前，页面已经实现了以下效果

最后一步，实现导出图片功能

导出功能

Konva内置了toDataURL功能，可以自定义导出的区域

 // 转dataURL 用于导出
  toDataURL(options = {}) {
    return this.stage.toDataURL(options);
  }

再封装一个用a标签下载图片的功能

export function downloadPNGForCanvas(
  dataURL: string,
  filename: string = (+new Date()).toString(),
) {
  const a = document.createElement('a')
  a.download = filename
  a.href = dataURL
  document.body.appendChild(a)
  a.click()
  a.remove()
}

ok, 可以实现导出功能了。
创建方格时，我给他们套了一个Rect，方便获取导出时width、height，xy坐标是Group的坐标。

const exportImage = () => {
  // 缩放回原始大小
  PixelRectGroup.value.scaleX(1)
  PixelRectGroup.value.scaleY(1)
  Stage.value.batchDraw()
  nextTick(() => {
    // 获取位置
    let { x, y } = PixelRectGroup.value.absolutePosition()
    let { width, height } = PixelRect.value.getAttrs()
    let dataURL = Stage.value.toDataURL({
      x,
      y,
      width,
      height,
      pixelRatio: window.devicePixelRatio, 
    })
    downloadPNGForCanvas(dataURL, '测试')
  })
}

最后用完成的功能画一个图试试看。
很明显啊，这是个掘金的标志，但是略微有些抽象，如果格子多一些后会好很多。
不过用手画还是略微有点慢呀，看来V2版本的导入图片自动绘制像素风要提上日程啦。

版本迭代

Pixeled Pic Pro的V1版本已经按照自己规划的内容完成了。本篇的代码，我会尽快更新到Github中。这次的版本定为v0.6.0，我会打一个tag标记。

后续有优化、功能迭代的话我都会按照文章所述的版本命名方式继续在Github中更新，感兴趣的朋友可以去Github 拉代码玩一玩，考虑到这个产品本体功能可能对大部分同学都不适用，所以大家仅参考我的开发过程和思考方式即可，前端或后端的V2版本，我会在整个产品的V1版本闭环后再酌情更新。

后续文章为： Nest实战篇、前端+后端部署篇、总结篇。总计五篇文章。我会收录在我的专栏/分类里方便大家查阅。

小结

下面是本次项目的总结：

合理的拆分需求，分阶段完成自己的目标
用一个现成的模版，快速启动前端项目，只要看到了成果，就对自己有正反馈。
文档没必要吃透，边做边查也很快，取自己所需即可
按拆分后列好的功能去逐步去实现，按自己的习惯、喜好去划分版本
碰到可复用的代码，先拆出来
收尾后及时总结归纳，加深印象

以上就是本篇全部的内容，文中有不正确、不清晰的地方，欢迎在评论区指出，我会尽快更正（不优雅不算）。

如果对大家能有一点点帮助，这将是我继续写下去的最大动力。

喜欢的朋友可以点个关注，继续追更后续的更多内容。有任何前端问题想要咨询的同学，也欢迎加VX：zzdaddy7，我会尽力为你解答。

感谢你的阅读，我是枣把儿~

（丑陋的彩蛋...）

当一个程序员突然想做一款产品

Wed, 06 Dec 2023 00:00:00 GMT

你一定有很多瞬间，脑子诞生了一个有趣的产品雏形，但因为种种原因搁浅，最终没有落地。

引言

在一个普普通通的周二，我又㕛叒一次萌生了和许多程序员一样的想法：做一款自己的产品。

鉴于以前的想法 99% 都变成了一个一个不能用的 demo，还有 1% 在反复起步，这次我痛定思痛，决心一定要好好“架构”一番！！

起步

说干就干。我熟练的打开Obsidian，打开Excalidraw 新建绘图，开始设计网站的草图，然后在一旁开始罗列想用的技术栈、表结构、功能点。一阵奋笔疾书后，一个网站的大概样子已经尽收我眼底！

正当我心中一阵窃喜时，我突然意识到我还缺一个Logo。

是的，这是一个非常严重的问题。虽然我还没有新建文件夹，但是这种建成后必定一流的网站要有一个配得上它的一流Logo才对。不行，我一定要为它找一个称心如意的Logo才行。但是今天已经快下班了，我只能明天再搞了。

ok，愉快的第二天马上就来了。

我开始从AIGC和自主设计两个方向寻找适合我的Logo，很快啊，AIGC被我排除了，因为它感觉就像一个不合格的Tony老师一样，不适合我这种精益求精的态度。

于是我打开b站，开始观摩几个设计领域的大up主，看看能不能吸取到一星半点的灵感（当然是只感受到了nb二字）。突然，我发现了一个搬运自YouTube的视频，再结合之前我在pinterest看到的让我眼前一亮的像素风格，就决定是你了！！

再起炉灶

我打开了我珍藏已久的Adobe AI , 想尝试按视频里的操作自己设计一番，但无奈它提示我因为某些原因不能继续使用了，并且只给了我退出软件和购买软件两个选项。我在微信提示余额不足后咬牙选择了退出。

既然如此，我只能自己先实现一个生成LOGO的工具了。（是的，像擦出爱情的火花一样突然）

（至于最开始是想做什么产品，我先按下不表）

功能构思

在分析了视频里的操作方式后，先在脑子构思一些这个小工具具体实现的功能：

一个可拖动的画布
一个可绘制的区域，区域内由带有黑色边框的小方格组成，并且可缩放可拖动。
小方格可以设置数量，如：100x100，单个方格可以设置大小，如格尺寸为：5x5
绘图模式下，鼠标可在绘图区域的小方格上点击并滑动，小方格会被设置对应的颜色
- 颜色可配置，并且方便切换：比如tab键自动轮换预制的几种颜色
绘制后，图片可导出
- 导出时，去除黑色边框？
- 导出时，去除未涂色的方格？
- 导出时，批量设置未涂色的方格颜色？
- 导出时，压缩图片？
导入一个图片，分析图片的像素值，自动绘制到画布上
- 图片要不要限制大小？
- 导入的图片在前端分析还是在后端分析？
- 在后端分析的话，如何设计一个上传接口，且避免自己的服务器被挤爆？
- 分析一个图片像素分布的插件、算法是不是已经有类似的库可以直接拿来用？
- 如果自己手写一个分析像素值的功能，如何设计采样的步长最合理，最高效？
- ~~不会已经有AI可以直接替代我这个产品了吧？~~（想到这里，我狠狠的打了自己一个大嘴巴子！想起了以前各种没出世的小产品，我决不能再找到一个理由不去完成这个产品）

构思到这里，我已经可以在脑子里完整的走完【生成像素LOGO】这个功能。

这算是一个产品经理立项的过程了，先聆听客户需求-> 再分析和拆解-> 以一个产品的形态实现客户的需求-> 梳理成文档发给研发部门或开项目启动会

后面可能还会有交底、反交底、UI评审、测试用例评审等等会议，这里出于产品本人即是UI又是开发，在大家的一致赞同下就跳过了。

技术栈选择

围绕着这些要实现的功能，我作为一个开发，首先想到了两种方向：

第一个是原生dom。

没错，在这个卷虚拟dom卷的没边儿的年代，我还能想到用原生dom来实现这个功能，实在是不忘初心，值得一个点赞和关注。

绘制方格、鼠标事件、控制涂色、导出图片，这些看起来都不是问题。

问题是：怎么控制这多dom一起缩放和拖拽？

由于感觉实现起来比较繁琐，不够优雅，加上这方面没有经验，以免被不能解决的问题卡住。

我开始思考第二个方向：Canvas。

先找别人做好的轮子。

Fabric
Konva
Pixi

在经过不长时间的google之后，我分别尝试了这三个插件，且看到了一个关于这种canvas库的性能对比网站。最终选择了Konva。

因为它内置了图层、图形、选择、变形、拖转、鼠标事件、导出图片/json等常用功能，比较是最贴合我的需求的，并且中文文档和英文的Api文档还算友好。

关于性能，这是一个在技术选型时经常提到的问题。但事实就是，不是每个产品的量级都会发展到那么大，你在考虑几万、几十万、几千万用户或者多么多么复杂的渲染场景的时候，却连第一个真实用户都还没有？更何况我这是个没人用的工具(⊙︿⊙)

为不存在的用户绞尽脑汁的进行性能优化，不如先为第一个用户实现主体功能

毕竟后续的优化也是KPI嘛

解决了核心库的选择，剩下的就是围绕项目搭建所用的技术了

前端

前端技术的选择，秉承着用新不用旧的原则，全部用最新的技术栈，也不考虑兼容问题。所以我选择了以下技术：

后端

既然是大前端，肯定优先选择Node，尽量把JS玩明白。

因为它的应用场景不光是页面或者Api服务，还包括客户端、命令行、各类编辑器插件、某些写作软件的插件、浏览器插件、爬虫、自动化等等。熟练后，使用范围非常广，可玩性非常强。

并且，司以为，业务层注重的应该是业务逻辑、思维逻辑，并不是你选了什么编程语言做后端，就可以避免屎山代码，就比别的语言优雅。

所以Node作为一个链接数据库和前端/客户端，提供一定量的稳定服务的编程语言，对我来说足矣。

再插一嘴选TS还是JS的问题，除了核心问题和选什么语言一样外。在工作上保持一定的挑战性对个人的成长很有帮助，所以建议还想成长的前端er，无脑选TS，走在薪资的前沿总是没有错的。

Node版本选择：

我目前是16.20.2 ，16的稳定版， 18、 20 也是可以的，我记得Vite5已经不支持低于18的版本，所以家里有条件的可以直接从20用起了。（偶数版本是稳定版）

Node框架选择：

Nest ：Node框架的不二之选。搭配TypeScript使用，既能学习到后端业务如何设计，又能参考目录接口如何设计，又能感受和使用TypeScript，一石三鸟。

服务器

阿里云服务器，前一阵搞活动99元/年，还是很划算的。

牵扯到的备案、域名、Nginx+Https，后续上线篇会展开讲讲。

部署方式

Docker

用docker跑nginx、redis、mysql，这样本地和服务器环境能尽量保持一致，还能提前验证问题。不至于本地开发完没问题，部署上去又出现各种问题

至此，一个从产品立项、到技术选型、最后到运维部署的流程已经梳理完成。下一步就是具体实现各个功能了！

小结

源于一个突发的灵感，在纠结了它到底对谁有用之后，我决定先上手实现它。

也许功能对其他人没用，但记录和写作的过程对我很有用。

如果对新入行的同学，也能有一点点启发和带动作用，这将是我继续写下去的最大动力。

喜欢的朋友可以点个关注，继续追更后续的技术篇。有任何前端问题想要咨询的同学，也欢迎加VX：523748995，我会尽力为你解答。

感谢你的阅读，我是枣把儿~

早早集市

给 OpenClaw 新增一个 Agent（以飞书机器人为例）

给 OpenClaw 新增一个 Agent（以飞书机器人为例）

你需要准备什么

第一步：创建 Agent 工作目录

第二步：写核心配置文件

SOUL.md — Agent 的灵魂

IDENTITY.md — 名字和角色

AGENTS.md — 工作规范

USER.md — 用户是谁

MEMORY.md — 长期记忆（不能省！）

HEARTBEAT.md 和 TOOLS.md

第三步：软连接 Skills（可选）

第四步：修改 openclaw.json

1. 在 agents.list 数组里加入新 Agent

2. 在 channels.feishu.accounts 里加飞书账号

3. 在顶层 bindings 数组里加路由规则

第五步：重启 OpenClaw Gateway

第六步：飞书开发者后台配置

第七步：验证

踩坑清单

⚠️ 坑一：漏加 bindings

⚠️ 坑二：飞书长连接顺序搞反了

⚠️ 坑三：没有 MEMORY.md 导致身份错乱

⚠️ 坑四：改完配置忘了重启

⚠️ 坑五：以为 account 字段就是路由

openclaw 文生图 SKILL 从发现到落地的核心思路分享

核心思路

SKILL的局限性

结语

OpenClaw 的主模型选什么，非常有说法

假设你是AI，你的Skill应该是什么样的

最近使用 openclaw 和 opencode 的几条感悟

Claude Code Remote Control：把手机变成遥控器，Claude 在你电脑上继续跑

这功能到底是啥

怎么用（最短路径）

安全性：不是“谁拿到 URL 谁就能控你电脑”

目前谁能用

我觉得最有用的两个场景

1) 走动/开会间隙：把等待变成推进

2) 临门一脚：不用回工位也能收尾

一个提醒

我的结论

opencode：exec 环境 model_not_supported 排查

背景

现象

排查过程（最小化）

结论

解决方法

规范驱动开发错在哪了

OpenClaw v2026.2.21 的一个“看起来很小”的修复：interval Heartbeat 不再被缺失 HEARTBEAT.md 卡死

这条修复到底解决了什么

为什么我觉得它值得写出来

我会怎么验证（给自己/也给你）

顺手一提：别让“缺文件”变成单点故障

OpenClaw v2026.2.21：Gemini 3.1、豆包/BytePlus 接入、Discord 语音 `/vc`，以及 Heartbeat 行为修复

Models/Google：新增 Gemini 3.1 支持

Providers/Onboarding：新增 Doubao 与 BytePlus（并对齐鉴权/文档）

Discord/Voice：新增 /vc + realtime voice auto-join

Heartbeat/Cron：修复 interval heartbeat 行为

我会怎么升级（偏谨慎）

OpenCode v1.2.10：别再多起一个 sidecar 了（以及 SDK 打包目录的小改动）

Desktop：默认是 localhost server 的时候，不再 spawn sidecar

SDK：构建产物改到 dist/，而不是 dist/src

贡献者

我会怎么升级

OpenClaw v2026.2.19：Apple Watch companion、设备移除流程，以及「无鉴权 HTTP」审计提醒

Apple Watch companion MVP：手表上也能看 inbox / 通知

Gateway/CLI：新增配对设备移除/清理流程（终于能体面地删设备了）

Security/Audit：当 gateway.auth.mode="none" 时，新增「gateway.http.no_auth」审计发现

Telegram/Cron/Heartbeat：修复 topic 目标投递，定时任务更稳

我会怎么升级（偏向建议升级）

opencode v1.2.6：少一次“无意义的 LLM 调用”，再加一把 GitLab 和 SQLite 的料

我挑出来的几个关键点

1）Core：新增 dfmt（D 语言格式化器）支持

2）Core：GitLab provider / auth 升级，支持会话中途 token 刷新

3）Core：移除“每条消息都生成标题”的 LLM 调用

4）TUI：attach 新增 --continue / --fork

5）TUI：从 JSON 存储迁移到 SQLite（带迁移命令）

我会怎么升级（偏保守但省心）

1. 在 `agents.list` 数组里加入新 Agent

2. 在 `channels.feishu.accounts` 里加飞书账号

3. 在顶层 `bindings` 数组里加路由规则

Discord/Voice：新增 `/vc` + realtime voice auto-join

4）TUI：`attach` 新增 `--continue` / `--fork`