[{"title":"2026 全球主流 AI 厂商百科全书：Agent 与推理觉醒时代","url":"/2026/03/25/ai%E5%8E%82%E5%95%86%E4%BB%8B%E7%BB%8D/","content":"

2026 全球主流 AI 厂商百科全书

\n

步入 2026 年，AI 模型已经从被动一问一答的“对话助手”彻底进化为“全自动智能体（Agent）”与“深度推理专家”。本文将全景盘点当前处于行业金字塔顶端的顶尖大模型，以及那些凭借庞大生态强势破局的“新势力”，并附上最硬核的跑分与定价对比。

\n
\n\n\n

\"AI
(图：2026 年的 AI 已经深度融入算力网络与自动化流水线)

\n
\n

🌐 国际三巨头：AGI 的领跑者

1. OpenAI (ChatGPT 5.4) —— 推理与多模态的绝对霸主

OpenAI 在 2026 年推出的 ChatGPT 5.4 彻底打破了常规对话的局限，其最大的技术飞跃在于深度引入了“思考力控制（Reasoning Effort）”机制。它不再是盲目输出，而是会在复杂的数学和代码问题上“停下来思考”。

\n\n

\"OpenAI

\n
\n

2. Anthropic (Claude 4.6) —— 程序员的赛博真神

被誉为“程序员之神”的 Anthropic，在 Claude 4.6 世代把代码能力推向了不可思议的新高度。它不仅懂代码，更懂复杂的工程架构。

\n\n

\"Claude
(图示意：Claude 4.6 直接读取 IDE 并在终端执行测试脚本的自动化工作流)

\n
\n

3. Google (Gemini 3.1) —— 算力巨兽与多模态天花板

凭借深厚的底层 TPU 算力与 Google Workspace 全家桶，Gemini 3.1 成为了原生多模态与超长上下文的“巨无霸”。

\n\n

\"Google

\n
\n

🇨🇳 国内三强：极客精神与 Agent 原生

1. 月之暗面 (Kimi 2.5) —— 你的专属 Agent 集群

Kimi 早已不是那个只能“吃长文”的助手，2026 年的它，更像是一个拥有无数个分身的项目经理。

\n\n

\"Kimi
(图示意：Kimi 2.5 后台多个智能体协作处理复杂代码的流水线)

\n
\n

2. MiniMax 2.7 —— 自我进化的性价比狂魔

在 2026 年异军突起的 MiniMax，主打“高情商”、“极速”与“全网最低的 Token 成本”。

\n\n
\n

3. 智谱 AI (GLM 5) —— 学院派的工程重器

作为清华系学院派的代表，智谱的 GLM 5 在企业级工程化与科研学术领域表现出了极其硬核的特质。

\n\n

\"GLM
(图示意：GLM 5 处理海量服务器集群日志并输出可视化分析研报)

\n
\n

🚀 并非首选，但绝不可忽视的“生态破局者”

1. xAI (Grok 3) —— 无法无天的实时信息网

埃隆·马斯克旗下的 Grok 3 深度绑定了 X (原 Twitter)。

\n\n

\"xAI

\n

2. 字节跳动 (豆包 Doubao) —— 卷王之王的语音与下沉市场

依托抖音和飞书的庞大生态，豆包大模型 在 2026 年打出了“地板价”的王牌。

\n\n

3. 阿里云 (通义千问 Qwen 3) —— 开源界的带头大哥

Qwen 系列在 2026 年依然是开源社区最亮眼的星。

\n\n
\n

💬 真实用户体验与网络吐槽 (Real-World UX)

纸面数据再强，也敌不过用户的“键盘投票”。以下是 2026 年各大社区（V2EX, Reddit, 掘金）对这些厂商最真实的评价：

\n\n
\n

📊 2026 大模型硬核数据对比 (核心整合)

进入 2026 年，单纯比拼 Token 价格已不够，很多模型在生成答案前会消耗大量隐性的“思考 Token (Reasoning Effort)”。以下是当前主流厂商的硬核对比数据：

\n

1. API 价格对比 (每 1M Tokens，美元计价基准)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
模型版本输入价格输出价格 (含推理预估)核心卖点与生态优势
豆包 Doubao-Pro$0.05$0.20📉 地板价之王，原生支持极低延迟语音
MiniMax 2.7$0.30$1.20🤑 性价比极高，适合大规模 Agent 并发部署
通义千问 Qwen 3$0.40$1.50阿里云生态深度绑定，开源微调基座首选
Kimi 2.5$0.60$2.50长文本无敌，国内智能体 (Agent Swarm) 体验最佳
GLM 5$1.00$3.20企业私有化部署标杆，工程研报专精
Grok 3$2.00$10.00🐦 独占 Twitter 实时数据流，无内容审查
Claude 4.6 Sonnet$3.00$15.00国际中端性价比之王，程序员全自动 Debug 核心
ChatGPT 5.4 标版$2.50$15.00综合能力标杆，多模态最强
Gemini 3.1 Pro$2.00$12.00原生百万级上下文，Google 全家桶深度整合
Claude 4.6 Opus$15.00$75.00昂贵，但逻辑无懈可击，适合架构级重构
ChatGPT 5.4 Pro$30.00$180.00💎 土豪专属，极长思考时间，最高算力倾斜
\n

2. 个人/开发者订阅套餐对比

\"Subscription

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
厂商个人标准版月费旗舰/Pro版月费适用场景
豆包免费/极低门槛￥99 /月语音陪伴、轻度日常问答
MiniMax￥29 /月￥199 /月学生党、独立开发者尝鲜
GLM / Qwen￥40 /月￥159 /月企业报表处理、云服务资源管理
Kimi￥49 /月￥699 /月深度内容创作者、重度 Agent 玩家
Grok (X Premium)$16.00 /月$22.00 /月币圈玩家、时政新闻记者
Google$19.99 /月$249.99 /月谷歌生态重度用户、海量文档研究员
Anthropic$20.00 /月$100+ /月全栈程序员、需要 Computer Use 控制电脑的人
OpenAI$20.00 /月$200.00 /月追求极致多模态体验、最前沿 AGI 信仰者
\n

3. 核心能力评测标杆

\n
\n

💡 2026 总结：你的数字外脑选型决策树

在这个能力严重溢出的年代，选型的核心在于你的工作流属性与生态绑定度：

\n
┌─────────────────────────────────────────────────────────┐
│                    2026 选型决策树                         │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  需要极客级的自动写代码/改Bug/接管电脑屏幕?                 │
│    ├─ 预算充足，追求极限 → Claude 4.6 Sonnet            │
│    └─ 开源微调，自建生态 → Qwen 3 Coder                 │
│                                                         │
│  需要处理长文本、海量文件、或者打造自己的 Agent 集群？        │
│    ├─ 具备海外节点，深度使用谷歌 → Gemini 3.1           │
│    └─ 国内直连，中文语境最佳 → Kimi 2.5                 │
│                                                         │
│  需要获取极速的实时新闻、无审查的锐评？                     │
│    └─ 直接上 → Grok 3 (绑定 X)                          │
│                                                         │
│  需要大规模高并发处理，或者打造语音客服系统？               │
│    ├─ 极高性价比，智能进化 → MiniMax 2.7                │
│    └─ 地板价，极限语音拟真 → 豆包 Doubao                 │
│                                                         │
│  需要解决顶尖的学术/数学/逻辑难题，且不在乎钱？             │
│    └─ 直接拉满思考时间 → ChatGPT 5.4 Pro (Thinking)     │
│                                                         │
└─────────────────────────────────────────────────────────┘
\n\n
\n

⚠️ 避坑指南：在调用 ChatGPT 5.4 或 Claude 4.6 进行简单的日常闲聊时，请务必调低 API 的 reasoning_effort (思考力度) 参数。否则隐形成本会让你月底的账单直接爆炸！

\n
\n
\n

相关推荐

\n\n","categories":["知识库"],"tags":["技术","AI","行业分析","大模型"]},{"title":"2026 AI 编程与开发工具深度对比：从 Cursor 到 Gemini CLI","url":"/2026/03/25/ai%E5%8E%82%E5%95%86%E5%AF%B9%E6%AF%94%E5%88%86%E6%9E%90/","content":"

2026 AI 编程与开发工具深度对比

\n

2026 年，写代码的方式彻底变了。我们不再逐行敲击键盘，而是作为“架构师”，指挥着一群不知疲倦的 AI 智能体 (Agents) 为我们打工。本文将深度剖析当前市面上最主流的 9 款 AI 开发神器。

\n
\n\n\n

\"AI
(图：2026 年的开发日常 —— 喝着咖啡看 Agent 重构代码)

\n
\n

🛠️ 核心阵营划分

2026 年的 AI 工具市场已分化为四大流派：

\n
    \n
  1. IDE 原生派 (AI-First IDEs): Cursor, Trae, Antigravity
    2. \n
  2. 终端智能体 (CLI Agents): Claude Code, Gemini CLI, Kimi Code
    3. \n
  3. 插件与桌面端 (Plugins & Apps): GitHub Copilot, Codex App
    4. \n
  4. 开源极客派 (Open Source): OpenClaw
    5. \n
\n
\n

1. IDE 原生派：代码编辑器的新王

如果你不想折腾配置，开箱即用的 AI IDE 是最佳选择。

\n

Cursor —— 依然是无可争议的王者

\n

Trae (字节跳动) —— Vibe Coding 的倡导者

\n

Antigravity (Google) —— 端到端测试核武器

\n

\"IDE

\n
\n

2. 终端智能体 (CLI Agents)：黑客的终极浪漫

真正的极客从不离开 Terminal。2026 年的终端工具已经可以接管整个操作系统。

\n

Claude Code —— 逻辑天花板

\n

Gemini CLI —— 性价比与搜索之王

\n

Kimi Code —— 本土化的 Agent Swarm

\n
\n

3. 插件与桌面端：稳健的经典流派

GitHub Copilot (2026 版)

\n

Codex App (OpenAI)

\n
\n

4. 开源黑马：OpenClaw

如果你是一个重度掌控欲患者，OpenClaw（原名 Moltbot）是 2026 年不可不试的神器。

\n\n

\"Open
(图：在终端中运行的开源智能体正在疯狂拉取依赖并编译)

\n
\n

🔥 开发者真实体感与吐槽 (Developer UX & Pain Points)

任何工具都有其暗面。在 2026 年的高强度开发流中，这些工具暴露出了哪些最真实的痛点？

\n\n
\n

💡 2026 架构师选型建议

在 2026 年，不要试图用一个工具解决所有问题，Multi-tool Stacking (多工具堆叠) 才是王道。

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
你的开发需求推荐的工具组合预期成本
追求极致的开发与重构体验Cursor (写代码) + Claude Code (跑终端 Agent)~$40 / 月
性价比之王 / 学生党Trae (免费版) + Gemini CLI (白嫖额度)免费
接私活 / 快速原型交付Antigravity (利用 Browser Agent 搞定 UI 测试)~$20 / 月
高度定制化 / 极客玩家OpenClaw (本地部署) + Kimi K2.5 API按量计费 (极低)
土豪 / 重度 GitHub 依赖Codex App Pro (云端沙盒极速编译)$200 / 月
\n
\n

👨‍💻 最终建议：让 AI 去写 boilerplate (样板代码)，把你的精力留给真正的系统架构和业务逻辑思考。未来的程序员，本质上都是 Agent 调度员。

\n
\n
\n

相关推荐

\n\n","categories":["知识库"],"tags":["技术","AI","效率工具","极客"]},{"title":"Arch Linux 试毒：初探邪教的诱惑","url":"/2026/02/25/arch-linux-part1/","content":"

“Arch Linux 是邪教，千万别碰！”

\n

这句在技术圈流传甚广的忠告，今天终于被我抛到了脑后。看着 Windows 11 日益臃肿的身躯、层出不穷的弹窗警告，还有在工地画图时突然给我来个蓝屏重启的绝望，我决定：是时候找点刺激了。

\n

今天（2月25日），我正式开始了 Arch Linux 的“试毒”之旅。

\n

为什么是 Arch？

其实我也考虑过 Ubuntu 或者 Manjaro，但骨子里那种“要想懂，就得从零开始手搓”的工程师强迫症犯了。Arch 的哲学——KISS (Keep It Simple, Stupid) 简直太吸引人了。你需要什么，就装什么；系统里没有一行代码是多余的。

\n

这不就像我们在工地上打灰一样吗？一切基础都要亲自夯实。

\n

第一次安装：被黑框框支配的恐惧

没有图形化安装界面？纯命令行？
讲真，看着屏幕上闪烁的光标，我有一瞬间怀疑自己是不是自虐。

\n

跟着 Arch Wiki 一步步：

\n
    \n
  1. 联网 (iwctl) - 这一步就卡了我半小时，因为宿舍网卡的驱动有点奇葩，最后我直接换数据了。
    2. \n
  2. 分区与格式化 (fdisk, mkfs) - 小心翼翼，生怕把用来吃饭的 Windows 数据盘给格了，但是还好之前预留好了空间，直接放在最后一个分区美滋滋。
    3. \n
  3. 挂载与基础包安装 (pacstrap) - 这一步跑起来的时候，看着那些包一个接一个飞过，心里竟然有点莫名的爽快？
    4. \n
\n

翻车记录（第一季）

就在我以为一切顺利，执行完 arch-chroot 准备收尾时，引导程序 grub 装崩了……但谢天谢地，实际上grub没崩，只是archlinux的grub无法被华硕的主板blos识别为引导，只要手动添加引导区路径就行了。

\n

\"修复引导并美化大成功\"

\n

孩子们，终于进去的，呃，kde怎么看起来像某银河麒麟。

\n

\"登录界面预览\"

\n
\n

📌 今日感悟：Arch 就像一个盲盒，你永远不知道下一个命令敲下去是惊喜还是崩盘。但这种掌控一切（或者被一切掌控）的感觉，属实有点上头。

\n
\n","categories":["技术随笔"],"tags":["Linux","折腾","Arch"]},{"title":"Arch Linux 日常：从“折腾”到“生产力”的进化之旅","url":"/2026/03/09/arch-linux-part3/","content":"

直到今天（3月9号），整整一周的高强度使用和不断调教，我终于敢说：Arch 不仅能活下去，而且比想象中更适合我的双重身份——开发者与工地施工员。

\n

这周我都折腾了什么？

    \n
  1. 环境与字体配置：
    解决了最初中文字体发虚和缺失的问题，现在我的终端和浏览器里，等距字体和各类 Nerd Fonts 混杂得极为和谐，阅读代码简直是享受。
    孩子们，不会QT和没用过环境变量的不要用这玩意。
    2. \n
  2. 包管理 (pacman & yay) 的终极快感：
    受够了去各种官网下载 .exe，然后提防捆绑安装的日子。在 Arch 里，一句 yay -S 软件名，几秒钟后软件就安静地待在启动器里了。无论是微信、Node.js 还是复杂的开发库，全都在掌控之中。
    3. \n
  3. 工作流重建：
    在工地需要处理的基础办公任务也找到了替代品。WPS 的 Linux 版出奇的好用；而绘图、修图等需求，也能在开源社区找到轻量又无广告的替代软件。
    4. \n
  4. 系统维护：滚动的恐惧与刺激：
    大家都说 Arch 是“滚挂”代名词。这周我确实遇到了一次因为特定包依赖冲突导致的无法启动 XWayland 的小问题。但是看报错日志、去论坛查疑、最终通过降级包修复成功的过程，让我学到了比用几年 Windows 还多的底层知识。
    实际上，现在arch已经很难滚挂了。
    5. \n
\n

给想跳坑朋友们的建议

如果只是一时兴起，或者每天离不开大型网游、专业级 Adobe 全家桶，那请留在 Windows。
但如果你有以下症状：

\n\n

那 Arch 绝对是你最终的归宿。

\n

试毒完成。目前看来，除了偶尔遇到点小麻烦需要自己阅读文档外，它已经完美地成为了我新的生产力平台。后续我还会在这里记录一些配置文件和踩坑记录，方便大家（或者以后的我）参考。

\n

生命不息，折腾不止！

\n","categories":["技术随笔"],"tags":["Linux","折腾","Arch"]},{"title":"孩子们，我不做 Windows 人啦！","url":"/2026/03/02/arch-linux-part2/","content":"
\n

“Are you sure you want to format /dev/nvme0n1p3?”
“Yes.”

\n
\n

就在 3 月 2 号的这个夜晚，我正式把装满了各种恶心管家、弹窗广告和强推组件的 Windows 分区，干！掉！了！

\n

才怪，孩子们，grub双引导和windows原生的dx12还是不错的，但是在此之前，我得把环境和生态全部搬过来。

\n

孩子们，我不做 Windows 人啦！(Jojo 脸.jpg)

\n

桌面与美化：从简陋黑框到酷炫极客

Arch 的安装这回轻车熟路了（感谢 archinstall 脚本的辅助，终于不用一行行敲命令了）。
装完系统才是真正折腾的开始。

\n\n

目前的极简桌面大概长这样：

\n

\"桌面效果\"

\n

现在的屏幕：一块透明模糊终端占据左边，右边跑着系统监视器，按下 Super + Enter 瞬间新开一个格子。敲击键盘的声音在深夜显得格外清脆。

\n

\"浏览器与窗口渲染效果\"

\n

工地人的倔强：软件能替吗？

最大的顾虑其实是生产力软件。
作为工地施工员，看图、发报表、偶尔码字是刚需：

\n
    \n
  1. 看图/ CAD：发现了好几款开源的看图软件，轻量又快速，虽然没法做深度编辑，但也足够应付。
    2. \n
  2. 沟通：微信和 QQ 直接用debtab一把梭，我从来没有那么感谢过国产信创提供的软件环境。
    3. \n
  3. 开发：不用说，Linux 就是代码的最佳归宿。
    4. \n
\n

今晚配置到凌晨两点，看着终于跑起来的完整桌面系统，有一种看着自己亲手浇筑的混凝土结构封顶的成就感。
明天起，迎接全新的生产力环境！

\n","categories":["技术随笔"],"tags":["Linux","折腾","Arch"]},{"title":"Vue 3 启航","url":"/2025/11/15/vue-learning-1/","content":"

梦开始的地方

记得刚接触前端的时候，大家还在用 jQuery 一把梭。那时候的代码充满了 $ 符号，回调地狱更是家常便饭，三件套东一块西一块是常态。后来 React 和 Vue 横空出世，带给了我们全新的组件化开发体验。而今天，我正式决定投入 Vue 3 的怀抱。

\n

为什么选择 Vue 3？

有人说 React 更灵活，有人说 Angular 更规范。但在我看来，Vue 3 找到了优雅与性能的完美平衡点。

\n
    \n
  1. 性能的质变：Vue 3 重写了响应式系统，利用 ES6 的 Proxy 取代了 Object.defineProperty。这意味着什么？意味着我们再也不用担心数组下标修改监听不到的问题了！而且，初始化的速度快得惊人。
    2. \n
  2. Composition API：这绝对是 Vue 3 最大的杀手锏。在 Options API 时代，一个功能的逻辑往往分散在 data、methods、computed 里，维护起来像是在玩“找你妹”。而现在，我们可以像这就写原生 JS 一样，把相关逻辑聚合在一起。这简直是代码组织的神器！
    3. \n
  3. TypeScript 支持：Vue 2 对 TS 的支持简直是灾难，而 Vue 3 是用 TS 重写的。这意味着我们在写 Vue 的时候，终于可以享受完整的类型推断了。再见，any scirpt！
    4. \n
\n

我的第一个 Vue 3 Demo

import { ref, onMounted } from 'vue'

export default {
  setup() {
    const count = ref(0)
    function increment() {
      count.value++
    }
  
    onMounted(() => {
      console.log('组件挂载完成！')
    })

    return { count, increment }
  }
}
\n\n

看着这简洁的代码，我仿佛看到了光明的未来。没有了 this 的困扰，一切都变得那么直观。

\n

\"激动\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","Vue3","学习"]},{"title":"Vite：快！太快了！由于速度太快我跟不上了","url":"/2026/01/10/vue-learning-10/","content":"

Vite：这也太快了吧… 还有报错

Vite 宣称是下一代前端构建工具。启动确实快，毫秒级。

\n

开发爽，打包火葬场

开发环境用的是 ES Modules，不需要打包，所以快。但是生产环境还是用的 Rollup 打包。
这就导致了一个极其恶心的问题：开发环境跑得好好的，一打包上线就报错！

\n

有些依赖包不是 ESM 格式，Vite 开发时会预构建解决，但在生产打包时，Rollup 的配置如果没有把 commonjs 转好，直接崩。我曾经为了一个老旧的加密库，折腾了整整两天 Vite 配置。optimizeDeps、rollupOptions、commonjsOptions… 每一个配置项都像是在嘲笑我的无知。

\n

心态崩了

毁灭吧，赶紧的。累了。

\n

我们先来聊聊 Vite 的核心概念。在官方文档中，这一部分被描述得非常晦涩难懂。我花了整整三天时间查阅源码，翻遍了 GitHub 上的 Issues，才勉强理解了其中的奥妙。简单来说，它就像是一个黑盒子，你输入 A，它输出 B，但中间发生了什么，只有上帝和尤雨溪知道。

\n

代码示例方面，我尝试写了一个 Demo，结果控制台满屏飘红。这哪里是写代码，简直是在扫雷。每一个变量的定义都充满了不确定性，每一个函数的调用都像是在赌博。

\n

\"Vite\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","Vite","工具"]},{"title":"前端性能优化：只要我跑得够快，Bug 就追不上我","url":"/2026/01/15/vue-learning-11/","content":"

性能优化：无底洞

说页面加载太慢，要优化。好，我优化。

\n

你知道的，一个three.js地图，配上一大堆数据，能加载的快就有鬼了。

\n

漫漫长路

    \n
  1. 代码分割（Code Splitting）：路由懒加载，组件异步加载。好，首屏快了一点。
    2. \n
  2. 图片压缩：上了 WebP，上了 CDN。
    3. \n
  3. 减少重排重绘：小心翼翼地操作 DOM。
    4. \n
  4. Tree Shaking：检查打包产物，去掉了无用的 lodash 引入。
    5. \n
\n

结果呢？

乐了，更卡了。

\n

心态崩了

毁灭吧，赶紧的。累了。

\n

为什么这么难？

前端不就是画画界面调调接口吗？为什么要搞这么复杂？Webpack 还没整明白，Vite 又来了；Vue 3 又变了。学不动了，真的学不动了。

\n

\"性能\"

\n","categories":["Vue学习之路"],"tags":["技术","Vue","前端","性能"]},{"title":"深坑记录：响应式丢失的那一夜","url":"/2026/01/21/vue-learning-12/","content":"

那个让我通宵的 Bug

那是周五的晚上，本该是快乐的周末开始。但是测试报了一个致命 Bug：用户点完保存，列表数据没有更新，必须刷新页面才行。

\n

排查过程

    \n
  1. 查接口：后端接口返回的数据是新的，没问题。
    2. \n
  2. 查 Vue DevTools：发现 store 里的数据确实可以更新，但是组件里的数据没变。
    3. \n
  3. 定位代码：
    4. \n
\n
// store.js
state: () => ({ list: [] })

// component.vue
const { list } = userStore
\n\n

就是这行解构！在 Options API 里习惯了 this.list，在 Setup 里直接解构 store，导致 list 变成了一个普通的数组，失去了响应性连接。

\n

心态崩了

毁灭吧，赶紧的。累了。

\n

我们先来聊聊 Vue 响应式的核心概念。在官方文档中，这一部分被描述得非常晦涩难懂。我花了整整三天时间查阅源码，翻遍了 GitHub 上的 Issues，才勉强理解了其中的奥妙。简单来说，它就像是一个黑盒子，你输入 A，它输出 B，但中间发生了什么，只有上帝和尤雨溪知道。

\n

为什么这么难？

前端不就是画画界面调调接口吗？为什么要搞这么复杂？Webpack 还没整明白，Vite 又来了；Vue 2 刚熟练，Vue 3 又变了。学不动了，真的学不动了。

\n

\"踩坑\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","Vue3","踩坑"]},{"title":"逐渐暴躁：为什么前端框架更新这么快？！","url":"/2026/01/22/vue-learning-13/","content":"

永远学不完

今天看到尤雨溪又发了新推特，Vue 3.5 即将发布，又有一堆新特性。Vapor Mode？无虚拟 DOM？

\n

求求了，别更新了。我 Vue 3.0 的文档还没背熟呢。

\n

疲惫感

每次打开 GitHub Trending，都是一堆新轮子。React Server Components, SolidJS, Svelte, Qwik… 每一个都号称颠覆前端。我累了，真的累了。

\n

作为一名追求极致体验的开发者，我深知持续学习的重要性。但是… 真的需要学这么多吗？

\n

AI 才是未来

不装了，我摊牌了。手写代码是上个世纪的事情了。今天我试了一下 Vibe Code，只需一句话，它就生成了我折腾了三天都没写出来的功能。那一刻，我释然了。我为什么要跟机器比速度？我为什么要跟编译器较劲？

\n

拥抱变化

回想起刚开始接触 Vue 的时候，那时候的快乐是纯粹的。写一个 {{ message }} 就能看到页面变化，那种成就感无与伦比。而现在，我们要处理复杂的依赖关系、难以捉摸的类型定义、层出不穷的构建工具配置。难道这就是成长的代价吗？

\n

真香！

\n

\"吐槽\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","吐槽","心情"]},{"title":"我累了：试图理解源码，结果被源码理解了","url":"/2026/01/23/vue-learning-14/","content":"

源码阅读：从入门到放弃

为了提升自己，我决定阅读 Vue 3 源码。打开 core 仓库，看到那几万行 TS 代码，我陷入了沉思。

\n

晦涩的渲染器

renderer.ts，几千行的 switch case，各种位运算标记（PatchFlags）。我看了一行，脑子就过载了。这就是大神的思维世界吗？

\n

我意识到，我可能这辈子都达不到这个水平了。我只是一个 API Consumer，一个熟练的搬砖工。

\n

转折点

就在我绝望的时候，我接触到了现在的 AI 编程工具。

\n

AI 才是未来

不装了，我摊牌了。手写代码是上个世纪的事情了。

\n

AI 降维打击

今天我试了一下 Vibe Code，只需一句话，它就生成了我折腾了三天都没写出来的功能。那一刻，我释然了。我为什么要跟机器比速度？我为什么要跟编译器较劲？

\n

从今天起，我不再是前端切图仔，我是 AI Prompt 工程师。Vue 3？真不熟。Pinia？没听过。我只知道 “Generate a login page with Vue 3 and Tailwind”。

\n

真香！

\n

\"源码\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","源码","放弃"]},{"title":"彻底放弃：拥抱 Vibe Code，AI 才是亲爹","url":"/2026/01/24/vue-learning-15/","content":"

最终章：拥抱未来

这是我《Vue 学习之路》系列的最后一篇文章。因为，这路我不走了。

\n

为什么放弃？

    \n
  1. 效率差距：我写个增删改查页面，要 4 小时，调 CSS 还要 1 小时。AI 写，只要 30 秒。
    2. \n
  2. 知识焦虑：前端技术栈爆炸，学不完。但 AI 已经学完了所有文档。
    3. \n
  3. 幸福感：写代码是为了创造产品，不是为了修 Bug。
    4. \n
\n

Vibe Code 体验

打开 Vibe Code，输入：“做一个博客首页，要有毛玻璃效果，基于 Hexo Butterfly 主题风格”。
然后，啪！代码出来了。没有语法错误，没有类型报错。

\n

那一刻，我感觉自己之前的努力就像个笑话。

\n

拥抱变化

从今天起，我不再是前端切图仔，我是 AI Prompt 工程师。Vue 3？真不熟。Pinia？没听过。我只知道 “Generate a login page with Vue 3 and Tailwind”。

\n

在这个快速发展的前端时代，技术的更新迭代速度简直让人窒息。每一次框架的更新，不仅带来了新的特性，也带来了新的焦虑。作为一名追求极致体验的开发者，我深知持续学习的重要性。但是… 真的需要学这么多吗？

\n

再见了，所有的未定义变量，再见了所有的代码不规范，node_modules。你好，DeepSeek。

\n

真香！

\n

\"真香\"

\n","categories":["Vue学习之路"],"tags":["AI","Vue","前端","Vibe Code"]},{"title":"Ref vs Reactive：响应式的哲学思考 (头秃篇)","url":"/2025/11/30/vue-learning-2/","content":"

响应式的哲学

在深入学习 Vue 3 的过程中，不管是新手还是老鸟，都会遇到一个经典问题：ref 和 reactive 到底用哪个？

\n

官方的定义

\n

看起来很简单，对吧？ref 处理基本类型，reactive 处理对象。但是在实际开发中，情况远比这复杂。

\n

踩坑实录

我曾经试图用 reactive 去定义一个数组，结果发现直接重新赋值会丢失响应性！

\n
let list = reactive([])
// ... 异步获取数据后
list = newData // ❌ 响应性丢失！界面不更新！
\n\n

为什么？因为 reactive 返回的是一个 Proxy 对象，直接赋值 list = newData 只是修改了变量 list 的引用，并没有修改原来的 Proxy 对象。

\n

正确做法是用 ref，或者用 list.push(...newData)。但是 ref 每次都要写 .value，真的好烦啊！在模板里倒是会自动解包，但在 JS 逻辑里，少写一个 .value 就能让你调试半天。

\n

深入思考

ref 更像是“指针”，明确地告诉我们这里有一个需要被追踪的值；而 reactive 则更贴近原生对象的直觉。

\n

简单来说，它就像是一个黑盒子，你输入 A，它输出 B，但中间发生了什么，或者是有没有响应到，你只能看输出和输入的情况。

\n

代码示例方面，我尝试写了一个 Demo，结果控制台满屏飘红。这哪里是写代码，简直是在扫雷。每一个变量的定义都充满了不确定性，每一个函数的调用都像是在赌博。

\n

也许，与其纠结用哪个，不如统一用 ref 一把梭？毕竟，显示地使用 .value 虽然繁琐，但至少心安。

\n

\"思考\"

\n","categories":["Vue学习之路"],"tags":["技术","Vue","前端","Vue3"]},{"title":"路由守卫：你是谁？你去哪？有通行证吗？","url":"/2025/12/05/vue-learning-3/","content":"

前端的保安：Vue Router

做单页应用（SPA），路由管理是绕不开的一环。而“路由守卫”（Navigation Guards）则是其中最精彩（也最容易出 Bug）的部分。

\n

全局前置守卫：beforeEach

这就好比小区门口的保安大爷，不管你是谁，进门先查证。

\n
router.beforeEach((to, from, next) => {
  if (to.name !== 'Login' && !isAuthenticated) {
    next({ name: 'Login' })
  } else {
    next()
  }
})
\n\n

看起来逻辑天衣无缝？只要没登录，就踢回登录页。但是！如果你的逻辑写得稍微有一点漏洞，就会陷入无限循环。

\n

比如，你忘记判断 to.name !== 'Login'，那么用户被重定向到 Login 页，再次触发 beforeEach，再次重定向… 浏览器直接卡死，你也懵逼了。

\n

组件内的守卫

beforeRouteEnter、beforeRouteUpdate、beforeRouteLeave。这些钩子函数让我们可以精确控制组件级的路由行为。

\n\n

遇到的困难与思考

对于路由守卫，社区里有很多争论。有人说它是未来，有人说它是过度设计。因为实际上后端配置JWT的情况下，并不需要这玩意。我个人认为，你还是要遇到回传需求的，这玩意总是有用的，而且并不是所有的服务都有完整后端。

\n

\"保安\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","学习","Vue Router"]},{"title":"生命周期钩子：生老病死，Vue 组件的一生","url":"/2025/12/14/vue-learning-4/","content":"

组件的一生

万物皆有灵，Vue 组件也不例外。它们从被创建（Creation），到挂载（Mounting），到更新（Updating），最后销毁（Unmounting），走完了一生。而我们开发者，就是那个掌握生杀大权的神。

\n

Vue 3 的变化

在 Vue 2 中，我们熟悉的是 created, mounted, destroyed。在 Vue 3 的 Composition API 中，这些变成了 onMounted, onUnmounted 等等。

\n

最让我困惑的是 setup()。它在 beforeCreate 和 created 之前执行。这意味着在 setup 里面，我们不需要写这一类的钩子了，直接写逻辑就行。

\n

实际应用中的坑

我曾经遇到过一个 Bug，在 onMounted 里面去获取 DOM 元素的高宽。理论上这时候 DOM 已经渲染好了，对吧？

\n

错！如果你的组件里面有 v-if 或者异步组件，onMounted 触发的时候，子组件可能还没渲染完！这时候拿到的高度是 0。解决办法是用 nextTick，或者检查你的组件结构。

\n

为什么会这样？

回想起刚开始接触 Vue 的时候，那时候的快乐是纯粹的。写一个 {{ message }} 就能看到页面变化，那种成就感无与伦比。而现在，我们要处理复杂的依赖关系、难以捉摸的类型定义、层出不穷的构建工具配置。难道这就是成长的代价吗？

\n

我们先来聊聊 Vue 生命周期的核心概念。在官方文档中，这一部分被描述得非常晦涩难懂。我花了整整三天时间查阅源码，翻遍了 GitHub 上的 Issues，才勉强理解了其中的奥妙。简单来说，它就像是一个黑盒子，你输入 A，它输出 B，但中间发生了什么，只有上帝和尤雨溪知道。

\n

代码示例方面，我尝试写了一个 Demo，结果控制台满屏飘红。这哪里是写代码，简直是在扫雷。每一个变量的定义都充满了不确定性，每一个函数的调用都像是在赌博。

\n

\"生老病死\"

\n","categories":["Vue学习之路"],"tags":["技术","Vue","前端","Vue3"]},{"title":"样式设计：CSS 也就是随便写写... (并没有)","url":"/2025/12/25/vue-learning-5/","content":"

CSS 的痛与乐

作为一个前端，最怕的不是写 JS 逻辑，而是调 CSS 样式。居中？对齐？适配？每一个词都能让猛男落泪。

\n

Vue 中的 Scoped CSS

Vue 提供了 <style scoped>，这简直是防止样式污染的神器。它通过给元素添加唯一的 data-v-xxx 属性，确保你的样式只在这个组件内生效。

\n
.example[data-v-f3f3eg9] {
  color: red;
}
\n\n

但是！当你试图修改子组件的样式时（比如修改 Element Plus 的组件样式），scoped 就变成了拦路虎。这时候你就得用深度选择器 :deep()。

\n
.parent :deep(.child) {
  /* 这样才能穿透过去 */
}
\n\n

之前不知道这个，我傻傻地去写全局样式，结果污染了整个项目，被组长骂了一顿。

\n

动态样式

Vue 3 允许我们在 CSS 中绑定 JS 变量：

\n
.text {
  color: v-bind(color)
}
\n\n

太酷了！这才是现代化开发嘛！

\n

样式设计看似简单，实则深不可测。Flexbox, Grid, CSS Variables, Tailwind… 学不完，根本学不完。

\n

\"CSS\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","CSS","设计"]},{"title":"Pinia：Vuex 的继任者，好吃又好用","url":"/2025/12/30/vue-learning-6/","content":"

菠萝（Pinia）真好吃

Vuex 复杂的 mutation, action, getter 曾让人头大。Pinia 的出现，简直是清流。

\n

为什么是 Pinia？

    \n
  1. 没有 Mutation：终于不用为了改个状态写那繁琐的模板代码了，直接在 Action 里改，或者直接改！
    2. \n
  2. TypeScript 友好：完美的类型推断，不用像 Vuex 那样写一堆泛型接口。
    3. \n
  3. 极简 API：defineStore 一把梭。
    4. \n
\n

逐渐掉光的头发

随着学习的深入，我发现事情并不像我想象的那么简单。Pinia 这个知识点，简直是我的噩梦。

\n

文档里写得轻描淡写，实际用起来坑巨多。比如，我在 store 里解构 state，结果响应性丢了！

\n
const store = useUserStore()
const { name } = store // ❌ 响应性丢失
\n\n

必须用 storeToRefs(store)。这种细节，一旦不知道，就是一下午的调试时间。

\n

令人头秃的细节

在这个快速发展的前端时代，技术的更新迭代速度简直让人窒息。每一次框架的更新，不仅带来了新的特性，也带来了新的焦虑。作为一名追求极致体验的开发者，我深知持续学习的重要性。但是，Pinia 的某些行为真的很迷。

\n

比如，它在服务端渲染（SSR）下的 hydration 问题，经常导致客户端和服务端数据不一致，你以为数据传过去了，结果是如传。我花了整整三天时间查阅源码，翻遍了 GitHub 上的 Issues，才勉强理解了其中的奥妙。简单来说，它就像是一个黑盒子，你输入 A，它输出 B，但中间发生了什么，只有上帝和尤雨溪知道。

\n

\"Pinia\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","Pinia","状态管理"]},{"title":"组件通信：Props 传值传到手抽筋","url":"/2025/12/31/vue-learning-7/","content":"

Props, Emit, Provide, Inject…

Vue 的组件通信方式多达十几种。父子通信用 Props/Emit，跨层级用 Provide/Inject，兄弟组件用 EventBus（Vue 3 移除了，得自己手写或用mitt），全局状态用 Pinia。

\n

传值的痛苦

当你有 5 层组件嵌套，最外层的组件想传个 ID 给最里面的组件。
Props Drilling（属性透传）简直是灾难。

\n

Parent -> Child -> GrandChild -> GreatGrandChild -> Target

\n

每一层都要声明 Props，写得我想吐。虽说可以用 provide/inject，但不仅失去了类型推断的便利（TS 还要额外定义 InjectionKey），而且数据流变得难以追踪。

\n

\"通信\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","Vue3","组件"]},{"title":"Composition API：逻辑复用的快乐与痛苦","url":"/2026/01/05/vue-learning-8/","content":"

组合式 API：双刃剑

Composition API 是 Vue 3 的灵魂。它允许我们将逻辑通过 Hooks（Composables）的方式进行提取和复用。

\n

理想很丰满

我想象中的代码：

\n
const { user } = useUser()
const { articles } = useArticles()
const { loading } = useLoading()
\n\n

清爽、干净、模块化。

\n

现实很骨感

实际写出来的代码：

\n
const { user, loading: userLoading, error: userError } = useUser()
const { articles, loading: articleLoading, error: articleError } = useArticles()
// 命名冲突！到处重命名！
\n\n

而且，如果你把所有逻辑都堆在 setup 里，不加以拆分，它就会变成一个巨大的面条代码（Spaghetti Code），比 Options API 还要难以维护。因为 Options API 至少强制你分开了 data 和 methods。严格来说实际上只要你不在乎史山代码，你完全可以不在乎getter和setter，全放在utils里面，所有的state变量都塞在一个const里面。

\n

令人头秃的细节

文档里写得轻描淡写，实际用起来坑巨多。比如那个 Hook 的执行时机，如果在 Hook 里面用了 onMounted，它到底是在父组件挂载前还是后？如果 Hook 里有异步操作呢？我之前是写C++这种顺序执行语言的，被这玩意狠狠的摆了一道，同一个函数内所有的调用是同步执行的，除非你用promise进行强行顺序化。

\n

\"API\"

\n","categories":["Vue学习之路"],"tags":["Vue","前端","Vue3","API"]},{"title":"TypeScript：给代码穿上防弹衣 (虽然很重)","url":"/2026/01/07/vue-learning-9/","content":"

TypeScript：心态崩了

毁灭吧，赶紧的。累了。

\n

无尽的报错

TypeScript 说是给代码穿上防弹衣，防止低级错误。但实际上，它更像是给我的手戴上了镣铐。

\n

Type 'string | null' is not assignable to type 'string'.
Property 'xyz' does not exist on type 'ABC'.

\n

我知道！我知道它是 null！我加了判断了！但 TS 就是不信！非要我写 as string 或者 !。

\n

尤其是在 Vue 组件的 Props 定义里，结合 defineProps 和泛型，写起来那叫一个酸爽。为了解决一个类型报错，我可能要写几十行的 interface 定义。这到底是写业务逻辑，还是在做类型体操？

\n

为什么这么难？

${title} 让我彻底破防了。我在 Pinia 里配了半天状态，结果组件里死活拿不到。控制台的黄色警告和红色错误交织在一起，像是在嘲笑我的无能。

\n

在这个快速发展的前端时代，技术的更新迭代速度简直让人窒息。每一次框架的更新，不仅带来了新的特性，也带来了新的焦虑。作为一名追求极致体验的开发者，我深知持续学习的重要性。但是… 真的需要学这么多吗？

\n

前端不就是画画界面调调接口吗？为什么要搞这么复杂？Webpack 还没整明白，Vite 又来了；Vue 3 又变了。学不动了，真的学不动了。

\n

\"TS\"

\n","categories":["Vue学习之路"],"tags":["技术","Vue","前端","TypeScript"]}]