193577746 (kyriewen)

手写 call、apply、bind：从原理到实现，附 3 个最容易忽略的边界情况

193577746 — Thu, 11 Jun 2026 18:40:58 +0800

本文手写实现 JS 中最重要的三个 this 绑定函数，并处理 90% 的人会忽略的边界问题。代码可直接复制。

一、准备知识：this 的优先级

call、apply、bind 都用于显式绑定 this。区别：

call：立即执行，参数逐个传递
apply：立即执行，参数以数组传递
bind：返回新函数，不立即执行，支持柯里化

手写它们的关键：将函数挂载到 context 对象上执行，然后删除。

二、手写 call

Function.prototype.myCall = function(context, ...args) {
  // 1. 处理 context 为 null/undefined 时指向全局对象
  context = context ?? window ?? global;

  // 2. 使用 Symbol 避免覆盖原对象属性
  const fnKey = Symbol('fn');
  context[fnKey] = this;

  // 3. 执行函数并获取返回值
  const result = context[fnKey](...args);

  // 4. 删除临时属性
  delete context[fnKey];

  return result;
};

测试：

function say(age) {
  return `${this.name} is ${age}`;
}
const obj = { name: '张三' };
console.log(say.myCall(obj, 25)); // "张三 is 25"

边界 1：context 为原始类型（number/string/boolean）时，需要转为对象。

// 改进
context = context !== null && context !== undefined ? Object(context) : window;

三、手写 apply

与 call 几乎一样，只是参数形式不同。

Function.prototype.myApply = function(context, argsArray = []) {
  context = context !== null && context !== undefined ? Object(context) : window;
  const fnKey = Symbol('fn');
  context[fnKey] = this;
  const result = context[fnKey](...argsArray);
  delete context[fnKey];
  return result;
};

测试：

say.myApply(obj, [30]); // "张三 is 30"

四、手写 bind（最难）

bind 的特点：

返回一个新函数
支持柯里化（预设参数）
当新函数作为构造函数（new）时，this 指向实例，而非绑定的 context

Function.prototype.myBind = function(context, ...presetArgs) {
  const fn = this;

  function bound(...restArgs) {
    // 关键：如果当前函数被 new 调用，this 指向实例，忽略绑定的 context
    const isNewCall = this instanceof bound;
    const ctx = isNewCall ? this : (context !== null && context !== undefined ? Object(context) : window);
    return fn.apply(ctx, [...presetArgs, ...restArgs]);
  }

  // 维持原型链（如果原函数有 prototype）
  if (fn.prototype) {
    bound.prototype = Object.create(fn.prototype);
  }

  return bound;
};

测试：

function Person(name, age) {
  this.name = name;
  this.age = age;
}
const boundPerson = Person.myBind({ x: 1 }, '李四');
const p = new boundPerson(28); // 作为构造函数，this 指向 p，忽略 {x:1}
console.log(p); // Person { name: '李四', age: 28 }

五、3 个最容易忽略的边界情况

边界 1：context 为 null/undefined

原生 call 会指向全局对象（浏览器 window，Node global）。我们的实现已处理。

边界 2：函数有返回值

必须将返回值传给调用方。已在实现中通过 result 返回。

边界 3：bind 后的函数作为构造函数

当使用 new 调用 bound 时，this 指向新创建的实例，不能继续绑定到原来的 context。
上述 myBind 中通过 this instanceof bound 判断即可。

验证：

function Base(age) {
  this.age = age;
}
const BoundBase = Base.myBind({ name: 'fake' }, 10);
const obj = new BoundBase(20);
console.log(obj); // Base { age: 20 } ，而不是 { name: 'fake' }

六、完整代码（可直接复制）

// call
Function.prototype.myCall = function(context, ...args) {
  context = context !== null && context !== undefined ? Object(context) : globalThis;
  const key = Symbol();
  context[key] = this;
  const result = context[key](...args);
  delete context[key];
  return result;
};

// apply
Function.prototype.myApply = function(context, argsArray = []) {
  context = context !== null && context !== undefined ? Object(context) : globalThis;
  const key = Symbol();
  context[key] = this;
  const result = context[key](...argsArray);
  delete context[key];
  return result;
};

// bind
Function.prototype.myBind = function(context, ...presetArgs) {
  const fn = this;
  function bound(...restArgs) {
    const isNew = this instanceof bound;
    const ctx = isNew ? this : (context !== null && context !== undefined ? Object(context) : globalThis);
    return fn.apply(ctx, [...presetArgs, ...restArgs]);
  }
  if (fn.prototype) bound.prototype = Object.create(fn.prototype);
  return bound;
};

七、总结

call 和 apply 的核心是 临时挂载 + 执行 + 删除。
bind 的核心是 返回函数 + 柯里化 + 判断 new 调用。
边界情况（null/undefined、原始类型、new 优先级）是面试和实际编码的常考点。

文中所有代码均已测试，可放心直接用于 polyfill。下一篇准备手写 instanceof 和 new 操作符，欢迎关注。

讨论：你还遇到过哪些 this 相关的奇怪 bug？评论区分享。

CSS Container Queries：彻底告别 @media 写到手软，附 5 个真实布局案例

193577746 — Wed, 10 Jun 2026 21:16:54 +0800

以前写响应式组件，总要根据视口宽度写一堆 @media，代码又臭又长。现在 Container Queries 让组件根据父容器尺寸响应，代码直接减半。本文讲透语法 + 5 个可直接复用的案例。

一、Container Queries 解决了什么问题？

@media 媒体查询基于视口宽度。这导致一个组件在不同父容器下无法独立响应——同样的卡片，在侧边栏和主内容区需要两套样式或者额外类名。

Container Queries 允许你定义：当父容器达到某个宽度时，子元素改变布局。

/* 以前：基于视口，无法区分卡片在哪个容器里 */
@media (min-width: 600px) {
  .card { display: flex; }
}

/* 现在：基于父容器宽度 */
@container (min-width: 300px) {
  .card { display: flex; }
}

二、基础语法（三步搞定）

2.1 定义容器

.sidebar {
  container-type: inline-size;   /* 监听内联方向（宽度）变化 */
  container-name: sidebar;       /* 可选，给容器起名 */
}

container-type: inline-size 最常用，表示根据宽度变化。
也可以 size（宽高都监听）或 normal（不监听）。

2.2 使用 @container

@container (min-width: 300px) {
  .card-title {
    font-size: 1.5rem;
  }
}

如果只有一个容器，可以直接写条件。如果有多个容器，用 container-name 限定：

@container sidebar (min-width: 300px) {
  /* 只对 sidebar 容器内的元素生效 */
}

2.3 组合与范围

@container (100px <= width < 300px) {
  /* 容器宽度在 100px 到 300px 之间 */
}

三、与 @media 对比（代码量减少 50%）

场景	传统 @media 做法	Container Queries 做法
卡片在侧边栏时垂直，在主区域时水平	写两套类名或全局判断	父容器定义后，卡片内一套规则自动适配
仪表盘小部件适应不同格子尺寸	根据视口断点统一控制	每个小部件独立响应自己的容器

代码对比：

<!-- 以前：需要额外类名 -->
<div class="sidebar">
  <div class="card vertical"></div>
</div>
<div class="main">
  <div class="card horizontal"></div>
</div>

/* 以前：手动控制 */
.card.vertical { flex-direction: column; }
.card.horizontal { flex-direction: row; }

/* Container Queries：一套规则 */
.card {
  container-type: inline-size;
}
@container (min-width: 400px) {
  .card { flex-direction: row; }
}
@container (max-width: 399px) {
  .card { flex-direction: column; }
}

四、5 个实战案例（可直接复制）

案例 1：卡片组件根据容器宽度切换布局

<div class="card-container">
  <div class="card">
    <img src="photo.jpg" alt="">
    <div class="card-body">
      <h3>标题</h3>
      <p>描述文字</p>
    </div>
  </div>
</div>

.card-container {
  container-type: inline-size;
}
.card {
  display: flex;
  flex-direction: column;
  gap: 1rem;
}
@container (min-width: 350px) {
  .card {
    flex-direction: row;
    align-items: center;
  }
  .card img {
    width: 40%;
  }
}

案例 2：侧边栏与主内容区共享同一卡片组件

/* 不需要任何额外代码，卡片自己响应父容器宽度 */
.sidebar { container-type: inline-size; width: 280px; }
.main { container-type: inline-size; width: 800px; }
/* 卡片规则如上，当父容器<350px时垂直，>350px时水平 */

案例 3：仪表盘小部件矩阵

<div class="dashboard">
  <div class="widget" style="width: 200px">...</div>
  <div class="widget" style="width: 400px">...</div>
  <div class="widget" style="width: 200px">...</div>
</div>

.widget {
  container-type: inline-size;
}
.widget-content {
  font-size: 12px;
}
@container (min-width: 250px) {
  .widget-content {
    font-size: 16px;
    display: flex;
    gap: 1rem;
  }
}

案例 4：商品列表切换行列（类似 Grid 与 Flex 混合）

.product-list {
  container-type: inline-size;
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}
.product-item {
  flex: 1 1 200px;
}
@container (max-width: 500px) {
  .product-item {
    flex-basis: 100%;  /* 小于500px时每行一个 */
  }
}

案例 5：自适应导航栏（折叠菜单）

<nav class="navbar">
  <div class="logo">Logo</div>
  <ul class="nav-links">
    <li>首页</li>
    <li>产品</li>
    <li>关于</li>
  </ul>
</nav>

.navbar {
  container-type: inline-size;
  display: flex;
  justify-content: space-between;
}
.nav-links {
  display: flex;
  gap: 1rem;
}
@container (max-width: 500px) {
  .navbar {
    flex-direction: column;
  }
  .nav-links {
    flex-direction: column;
    margin-top: 0.5rem;
  }
}

五、浏览器兼容性与降级方案

支持情况（截至 2026-06）：

Chrome 105+ ✅
Firefox 110+ ✅
Safari 16+ ✅
Edge 105+ ✅

如果需要兼容旧浏览器，使用 @supports 渐进增强：

/* 降级：默认样式（例如始终垂直） */
.card {
  flex-direction: column;
}
/* 支持 Container Queries 时覆盖 */
@supports (container-type: inline-size) {
  .card-container {
    container-type: inline-size;
  }
  @container (min-width: 350px) {
    .card {
      flex-direction: row;
    }
  }
}

六、总结

Container Queries 让组件根据父容器而非视口响应，实现真正的组件级响应式。
语法简单：container-type + @container。
5 个案例覆盖卡片、侧边栏、仪表盘、商品列表、导航栏。
兼容性已可投入生产，配合 @supports 安全降级。

文中所有代码均可直接复制到项目中。以后写响应式组件，先问自己：这个样式是由视口决定，还是由父容器决定？

讨论：你在开发中遇到过哪些因 @media 全局断点导致的组件复用困难？欢迎留言分享。

前端性能优化：LCP 从 4s 到 0.9s 的 5 个核心手段（附配置代码）

193577746 — Tue, 09 Jun 2026 18:17:18 +0800

一、LCP 的定义与优化目标

LCP（Largest Contentful Paint） 衡量页面最大内容元素（通常是图片、视频、大文本块）的渲染时间。优化目标：≤ 2.5 秒。

影响 LCP 的主要因素：

资源加载慢（图片、字体）
渲染阻塞（CSS、JS）
客户端渲染延迟

下面按优先级列出 5 个最有效的优化手段。

二、优化手段 1：图片优化（WebP + 响应式 + 懒加载）

原理

使用现代图片格式（WebP/AVIF）体积更小
不同设备加载不同尺寸，减少无效传输
非首屏图片懒加载

具体配置

WebP 替换（Nginx 自动协商）：

location ~* \.(jpg|jpeg|png)$ {
  add_header Vary Accept;
  if ($http_accept ~* "image/webp") {
    rewrite (.*) $1.webp break;
  }
}

响应式图片（HTML）：

<img
  srcset="hero-480w.webp 480w, hero-960w.webp 960w, hero-1440w.webp 1440w"
  sizes="(max-width: 600px) 480px, (max-width: 1200px) 960px, 1440px"
  src="hero-fallback.jpg"
  alt="description"
  loading="eager"
>

懒加载：

<img src="product-1.jpg" loading="lazy" alt="product">

收益

首屏图片传输体积减少 50%~70%，LCP 直接降低 1~2 秒。

三、优化手段 2：字体优化（font-display + 预加载）

原理

默认情况下，自定义字体下载期间浏览器会隐藏文字（FOIT），阻塞渲染
font-display: swap 先显示系统字体，字体加载后替换
预加载关键字体可提前下载

CSS 配置

@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main.woff2') format('woff2');
  font-display: swap;
}

HTML 预加载

<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

收益

消除字体阻塞，FCP 提前 0.5~1 秒，间接改善 LCP。

四、优化手段 3：JavaScript 分割与异步加载

原理

大型 JS bundle 会阻塞解析和渲染
代码分割 + defer 让非关键 JS 不阻塞首屏

Webpack 配置（splitChunks）

// webpack.config.js
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 20000,
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendors',
          priority: 10,
        },
      },
    },
  },
};

动态导入

// 需要时才加载
import('./heavy-module').then(module => {
  module.init();
});

第三方脚本延迟

// 在 load 事件后加载
window.addEventListener('load', () => {
  const script = document.createElement('script');
  script.src = 'https://analytics.example.com/tracker.js';
  document.head.appendChild(script);
});

收益

首屏 JS 体积减少 60%~80%，主线程空闲提前，LCP 改善 0.5~1 秒。

五、优化手段 4：CSS 内联关键样式 + 异步加载非关键样式

原理

外部 CSS 文件会阻塞渲染
首屏需要的样式（关键 CSS）内联到 <head>
完整 CSS 文件异步加载，不阻塞

提取关键 CSS（使用 `critical` 工具）

npm install -g critical
critical index.html --inline --base dist/ > index-critical.html

异步加载完整 CSS

<link rel="preload" href="/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/full.css"></noscript>

收益

消除 CSS 阻塞，FCP 提前 0.3~0.8 秒。

六、优化手段 5：服务器压缩与 CDN 预热

原理

Brotli 压缩比 Gzip 高 20%~30%
CDN 预热让用户首次访问即命中边缘节点

Nginx Brotli 配置（需编译 brotli 模块）

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

CDN 预热（阿里云示例）

aliyun cdn PushObjectCache --ObjectPath "https://example.com/static/main.js"

收益

传输体积减少 20%~30%，RTT 高的地区尤其明显。

七、优化优先级总结

优先级	手段	预期 LCP 收益	实施成本
1	图片 WebP + 响应式	减少 1~2 秒	中
2	字体 swap + 预加载	减少 0.5~1 秒	低
3	JS 代码分割 + defer	减少 0.5~1 秒	中
4	关键 CSS 内联	减少 0.3~0.8 秒	中
5	Brotli + CDN 预热	减少 0.2~0.5 秒	低

按此顺序执行，2 天内可将 LCP 从 4 秒以上降至 1.5 秒以内。

八、检测工具

Lighthouse（Chrome DevTools）
WebPageTest（https://www.webpagetest.org）
Chrome Performance 面板

以上所有配置均可直接复制使用。如有具体场景问题，欢迎讨论。

我读了一遍 Babel 编译后的 async/await，终于搞懂了它的原理（附 20 行手写实现）

193577746 — Mon, 08 Jun 2026 19:33:54 +0800

本文从一个真实项目 bug 出发，带你读 Babel 编译结果，然后手写一个最简 async/await。

1. 一个真实的 “翻车” 场景

上周维护一个老项目，看到同事写了这样的代码：

async function processItems(items) {
  const results = [];
  for (let i = 0; i < items.length; i++) {
    const res = await fetch(`/api/process/${items[i]}`);
    results.push(res);
  }
  return results;
}

他把 await 放在 for 循环里，本意是串行请求，结果因为接口响应时间不同，数据顺序全乱了。我帮他改成 Promise.all 后，突然意识到：我其实并不清楚 async/await 底层到底怎么工作的。

于是我去看了 Babel 把 async 函数编译成了什么样子——发现它只是一个 generator + 自动执行器 的包装。

这篇文章，我就用 20 行代码，带你手写一个最简版的 async/await。

2. 前置知识：Generator 函数

如果你已经熟悉 generator，可以跳过本节。

Generator 是可以暂停和恢复的函数：

function* gen() {
  console.log('step 1');
  yield 1;
  console.log('step 2');
  yield 2;
  return 3;
}

const g = gen();
console.log(g.next()); // { value: 1, done: false }
console.log(g.next()); // { value: 2, done: false }
console.log(g.next()); // { value: 3, done: true }

每次调用 next()，函数会执行到下一个 yield 并暂停。
这个特性正好可以用来模拟 await 的 “等待异步结果再继续” 的行为。

3. Babel 编译后长什么样？

写一个最简单的 async 函数：

async function getData() {
  const a = await Promise.resolve(1);
  const b = await Promise.resolve(2);
  return a + b;
}

用 Babel（@babel/preset-env）编译后（简化版），变成了类似这样的代码：

function getData() {
  return _asyncToGenerator(function* () {
    const a = yield Promise.resolve(1);
    const b = yield Promise.resolve(2);
    return a + b;
  })();
}

核心是 _asyncToGenerator 这个辅助函数——它接收一个 generator 函数，并返回一个自动执行该 generator 的函数，最终返回一个 Promise。

4. 手写核心：自动执行器

我们先写一个函数 run(generatorFunc)，它能自动执行 generator 直到结束。

function run(generatorFunc) {
  const generator = generatorFunc();   // 获取迭代器对象

  return new Promise((resolve, reject) => {
    function step(nextFunc) {
      try {
        const { value, done } = nextFunc();
        if (done) {
          resolve(value);
        } else {
          // 确保 value 是一个 Promise
          Promise.resolve(value).then(
            (res) => step(() => generator.next(res)),
            (err) => step(() => generator.throw(err))
          );
        }
      } catch (err) {
        reject(err);
      }
    }

    step(() => generator.next()); // 启动执行
  });
}

测试一下：

function* myGen() {
  const a = yield Promise.resolve(1);
  const b = yield Promise.resolve(2);
  return a + b;
}

run(myGen).then(console.log); // 输出 3

完美运行。

上面的 run 就是 _asyncToGenerator 最核心的逻辑。真正的 Babel 实现还处理了更多边界情况，但原理完全一致。

5. 封装成真正的 `asyncToGenerator`

如果你想让函数直接返回 Promise，可以这样封装：

function asyncToGenerator(generatorFunc) {
  return function(...args) {
    const gen = generatorFunc.apply(this, args);
    return new Promise((resolve, reject) => {
      function step(key, arg) {
        let result;
        try {
          result = gen[key](arg);
        } catch (err) {
          return reject(err);
        }
        const { value, done } = result;
        if (done) {
          resolve(value);
        } else {
          Promise.resolve(value).then(
            v => step('next', v),
            e => step('throw', e)
          );
        }
      }
      step('next');
    });
  };
}

用法：

const getData = asyncToGenerator(function* () {
  const a = yield Promise.resolve(1);
  const b = yield Promise.resolve(2);
  return a + b;
});

getData().then(console.log); // 3

和原生 async/await 行为完全一致。

6. 常见误解与踩坑

6.1 `await` 后面跟着的不是 Promise 会怎样？

await 123 会被隐式转换为 await Promise.resolve(123)，所以自动执行器里用 Promise.resolve(value) 包裹是正确的。

6.2 异步错误怎么捕获？

如果 generator 内部 yield 了一个 rejected Promise，自动执行器会调用 generator.throw(err)，然后在 try-catch 中 reject 最终的 Promise。所以外层的 .catch 可以捕获。

6.3 `for` 循环里的 `await` 是串行还是并行？

// 串行（一个接一个）
for (const id of ids) {
  await fetch(`/api/${id}`);
}

// 并行（同时发起）
await Promise.all(ids.map(id => fetch(`/api/${id}`)));

理解原理后，你就知道为什么串行会慢，以及什么时候该用 Promise.all。

7. 总结

async/await 的底层 = generator + 自动执行器
手写一个自动执行器只需 20 行左右
真正理解原理后，你就能轻松避免 “异步陷阱”
文中代码可以直接复制到你的项目中跑一跑

讨论：你在项目中遇到过哪些因不理解 async/await 原理而产生的 bug？欢迎在评论区分享你的 “翻车” 经历～

一个人 +Cursor，7 天上线付费小程序：第 1 天我就想放弃了

193577746 — Sun, 07 Jun 2026 12:20:40 +0800

凌晨两点，我盯着微信公众平台那个红色的 “审核不通过” 通知，心里只有一个念头：

要不这破项目就算了吧。

这是第一天。我原计划 3 天搞定全部，结果连一个类目选择都能卡我 4 个小时。而那个被全网吹上天的 Cursor，此刻正安安静静地躺在我的 MacBook 右侧，它什么也帮不了我。

一、一个冲动的开始：3 天上线一个付费工具？

事情的起因很简单。

女朋友在厨房贴了一张 “距离房租到期还有 XX 天” 的便利贴，我随口说了句：这玩意儿微信小程序做一个不就行了，还能设个付费去广告，一个月卖几块钱。

她白了我一眼：“你做啊。”

男人最受不了这种激将。我当场打开 Cursor，敲下一行注释：

// 一个倒计时小程序，用户可以创建多个倒计时事件，支持付费去广告

然后按下了 Cmd+K。

那一刻，Cursor 就像一个被打了鸡血的实习生，哗啦啦生成了整整三个页面：首页倒计时列表、创建页、设置页。甚至还自动配了一个好看的渐变背景。我靠在椅子上，看着屏幕上飞速滚动的代码，脑子里已经在算账了：一天开发、一天审核、一天接支付，3 天上线，完美。

事实证明，我天真得像个刚毕业的实习生。

二、第一道墙：Cursor 再强，也不知道 “个人主体不能选这个类目”

我用的个人主体注册小程序。

Cursor 生成的代码里，默认跳过了类目选择这个环节——对 AI 来说，这不就是一行配置吗？它甚至贴心地帮我选了一个 “工具 - 效率” 的类目，说这个最匹配。

但当我在 mp.weixin.qq.com 点下 “提交审核” 时，页面直接弹红：

“个人主体暂不支持该类目，请选择其他类目或申请企业主体。”

我懵了。

然后就是长达四个小时的循环：查类目表 → 换一个 → 再被拒 → 再换。我试图把需求丢给 Cursor：“微信小程序个人主体可选类目有哪些？” 它给了一串过时列表，其中一半已经不存在了。

最终我手动翻完了 2026 年 5 月版的《微信小程序开放的服务类目》，在一个叫 “工具 - 记账/提醒” 的犄角旮旯里找到了唯一能挂靠的选项。这整个过程，Cursor 一个字都没帮上。

我看了下时间，凌晨 1:47。原计划的第一天 “完成全部开发”，现在我连审核的入口都还没摸到。

三、AI 10 分钟写的代码，我花了一整天修 bug

第二天我学聪明了，先把基础功能跑通。

我把需求拆成小块喂给 Cursor：

生成一个微信小程序页面，展示用户创建的倒计时列表，使用云开发数据库，支持下拉刷新

10 秒，代码出来了。

我复制进去，编译，满屏报错。

排查了半小时，发现它用了 wx.cloud.database().collection('countdowns').get() 这种写法，但压根没告诉我需要先初始化云开发环境，还要在 app.json 里配 "cloud": true。

这就像请了一个代码写得飞快但从来不写文档的同事。你问他 “这个接口需要什么前提条件？”，他会一脸无辜地看着你：“你没问我啊。”

我索性坐下来，一条一条地调：云函数怎么部署、数据库权限怎么设、openid 怎么拿、倒计时渲染时的时区问题……每一个坑都得我手动填。Cursor 负责把砖头递过来，但砌墙的人只能是我。

到晚上 10 点，倒计时功能终于跑通了。创建、列表、详情、删除，一个最小闭环。代码量加起来也就 500 行，但我在 debug 上花的时间至少是写代码的 5 倍。

我在 Notion 上写下一句话：AI 能让你 10 分钟拥有一个可运行的 demo，但要把那个 demo 变成可上线产品，剩下 90% 的时间都在处理 AI 不知道的问题。

四、审核的毒打：AI 不知道 “中国式合规” 长什么样

第三天，我信心满满地提交了第一个版本。

4 小时后，驳回。

理由：“小程序涉及用户自定义内容输入，需接入内容安全 API。” 附了一个文档链接，密密麻麻的接口说明。

Cursor 知道这个吗？完全不知道。

它甚至不知道微信内容安全接口的存在。我试着把文档喂给它：“请根据这个文档，在用户创建倒计时标题时接入内容安全检测。” 它像模像样地写了一个请求函数，但把 mediaType 写成了 contentType，把返回值的结构完全搞错。

我放弃了让 AI 改，自己对着文档一行行手写。写完提交，又驳回。

这次理由更让人崩溃：“请在小程序首页明确展示备案号及开发者信息。”

我看了看 Cursor 生成的首页，漂亮的渐变背景上干干净净，只有一个标题 “我的倒计时”。它当然不会知道中国小程序需要展示备案号，这对它来说是不可理喻的需求。

来来回回，一共被驳回 7 次。理由包括但不限于：

未接入内容安全
未展示备案号
登录流程不符合规范（AI 写了静默登录，但微信要求显式授权）
付费功能说明不清晰
客服按钮没有
隐私协议链接缺失
甚至有一次说 “请在服务页面增加投诉入口”

第七次驳回通知弹出来的时候，我坐在椅子上笑了。那种笑不是开心，是 “原来做一个能上线的小程序，真正的门槛从来不在代码” 的顿悟。

五、转折：第四天晚上，审核突然过了

第四天下午，我把以上所有合规项一个一个改完。

不再信任 Cursor 直接生成任何跟审核相关的代码，我索性全部手写，只让它帮我做一件事：格式化代码、补全一些重复性的 UI 组件。

晚上 8 点，我点了最后一次 “提交审核”。

然后开始看剧，把自己放空。

11 点 23 分，手机震了一下。我瞟了一眼，微信公众平台的通知：

“你的小程序 ‘倒数日提醒’ 已通过审核。”

我愣了两秒，然后几乎是吼着跟女朋友说：过了！

她淡定地抬头：“哦，那能赚多少钱？”

……这个问题问得真好。

六、接入支付：技术不难，难的是 “你敢收钱吗”

审核通过后，第五天我开始接入微信支付。

这次 Cursor 终于有点用了。微信支付的云函数调用流程它很熟，我丢给它一句话：

云开发实现微信小程序支付，使用云函数统一下单，用户支付1元解锁去广告功能

它生成了两个云函数：createOrder 和 checkPayResult，结构基本正确。我只需要改一下商户号、回调地址和签名逻辑。这次，AI 的效率终于体现出来了：从开写支付代码到测试完成，只用了 2 个小时。

技术上的支付接入其实很快。真正让我犹豫的是心理那道坎：这玩意儿真有人付钱吗？

我设了个价格：去广告 1 元/永久。不是不想多收，是我自己都觉得一个倒计时工具收太多心虚。广告则是接了一个 Banner 广告位，不付费的用户每次打开倒计时详情都会看到底部广告。

一切就绪后，我自己用另一个微信号扫码，输入密码，支付 1 元。支付成功的提示弹出来那一刻，我突然有种莫名的感动——这就是独立开发者所谓的 “闭环” 吧。

七、第一笔真实的付费，来自一个陌生人

上线后的第一个白天，小程序安安静静，访问人数 12。

那 12 个人全是我自己拉的朋友，他们礼貌地点了点，夸了两句就走了。没有任何人付费。

我有点丧，但也在意料之中。

第六天晚上，我正在刷 B 站，微信支付商户助手突然弹了一条消息：

“支付到账通知：0.99 元。”

扣除手续费后 0.99 元，来自一个我完全不认识的用户，昵称是一个太阳的 emoji。他创建了一个倒计时：“距离下次发工资还有 23 天”。

我盯着这条通知看了很久。不是因为钱多，而是因为这是第一次，有陌生人愿意为我的代码付钱。

0.99 元，四舍五入就是一块。但这一块的重量，比我拿过的大厂月薪还让人心跳加速。

我立刻截图发了一个朋友圈，配文：“AI 时代，独立开发者的第一笔收入。” 评论区炸了，一半人恭喜，一半人问我怎么做到的。

八、复盘：AI 到底帮我省了多少时间？

整个项目结束后，我做了一个时间统计：

核心代码编写（倒计时逻辑、页面、交互）：如果纯手写，按我的速度大约需要 3 天。Cursor 生成 + 我修改，实际花了 4 小时。
环境配置、审核合规、支付资质：这些 Cursor 几乎帮不上忙，我花了 4 天。
调试和修复 AI 生成的 bug：花了 1 天半。
后期优化和 UI 微调：半天。

所以，AI 确实把编码部分加速了 90% 以上。但 “做一个小程序” 需要的远不只是编码。合规、审核、支付资质、用户心理、定价策略——这些才是真正吃掉时间的地方，而 AI 对此一无所知。

这也让我突然理解了，为什么很多独立开发者说 “Cursor 让我更忙了”——因为你可以一天生成三个项目，但后续的泥潭一个都绕不开。

九、这篇文章想告诉你什么

我知道很多同行刷掘金的时候，看到 “AI 10 分钟写一个小程序” 的标题会焦虑。我也焦虑过。但自己走完这 7 天，我反而平静了。

AI 消灭的不是程序员，而是 “只写代码的程序员”。

当 Cursor 可以把你的 CRUD 时间压缩到十分之一，剩下的竞争力是什么？

是知道怎么跟平台审核斗智斗勇。
是知道用户真正愿意为什么而付费。
是知道那个看似无用的 “备案号展示” 能让你免于下架。
是知道在什么时机把项目 push 到线上，并且在第一个 0.99 元到账时，还能像傻小子一样兴奋。

这些都是经验，是判断力，是踩坑踩出来的直觉。AI 暂时还学不会。

十、下一步：我要用 30 天验证一个更大的假设

这个倒计时小程序只是一个前哨。我真正的计划是从它开始，一个人 + Cursor，连续 30 天上线 3 款不同形态的小程序，都设 1 元付费点，测试不同赛道的真实需求。

第 2 个：一个随机决定工具（中午吃啥、周末去哪），带社交裂变
第 3 个：一个极简记账，只记支出，AI 自动分类

我会把每一个的过程、数据、收入截图全部公开在掘金。不造神，不贩卖焦虑，只记录一个真实的前端开发者，在 AI 工具大行其道的 2026 年，用最笨的方法一步一步走下去的样子。

从 Webpack 到 Vite：我们迁移了一个 10 万行代码的项目，总结了这 7 个坑

193577746 — Sat, 06 Jun 2026 19:18:25 +0800

一、为什么要迁？我们当时的痛点

项目技术栈：React 18 + TypeScript + Ant Design + less。Webpack 配置经过多人 “迭代”，已经变得极其复杂：各种 loader、plugin、alias、proxy，还有自定义的打包分析脚本。

痛点：

开发服务器启动：45 秒起步，同事可以泡杯咖啡
热更新：改一行代码，等待 3 秒才刷新
生产构建：6 分钟，CI 经常超时
配置维护：没人敢动 webpack.config.js，一动就崩

我们调研了 Vite，开发服务器启动秒级、HMR 极快、配置简单。决定迁移。

二、迁移过程与踩坑记录

坑 1：环境变量不兼容

Webpack 用process.env注入变量，Vite 用import.meta.env。全局搜索替换容易遗漏，特别是第三方库中使用了process.env。

解决：用@vitejs/plugin-react自带的define配置，手动映射：

// vite.config.js
export default defineConfig({
  define: {
    'process.env': process.env
  }
})

但这样会打包所有环境变量，有安全风险。建议只映射需要的：'process.env.API_URL': JSON.stringify(process.env.API_URL)。

坑 2：CommonJS 模块不兼容

Vite 默认只支持 ESM，但node_modules里有大量 CommonJS 模块。比如@ant-design/charts、moment等。

现象：提示Module not found或require is not defined。

解决：

先用vite-plugin-commonjs（已废弃），官方推荐optimizeDeps.include： js optimizeDeps: { include: ['@ant-design/charts', 'moment'] }
实在不行，在build.rollupOptions中配置@rollup/plugin-commonjs。

坑 3：less 全局变量失效

Webpack 中我们用less-loader的modifyVars全局注入主题变量。Vite 不支持这种写法。

解决：用vite-plugin-style-import或直接修改 vite 配置的 css 预处理器选项：

css: {
  preprocessorOptions: {
    less: {
      modifyVars: { '@primary-color': '#1890ff' },
      javascriptEnabled: true
    }
  }
}

但这样只对组件库有效，自己写的 less 文件还需要手动@import全局变量文件。

坑 4：动态导入路径问题

代码中大量使用import(@/pages/${pageName}/index)动态导入。Vite 要求动态路径必须静态可分析。

现象：构建时提示The requested module '...' does not provide an export named 'default'。

解决：改用const modules = import.meta.glob('./pages/**/index.tsx')，然后手动匹配。

坑 5：代理重写规则不一致

Webpack 的devServer.proxy和 Vite 的server.proxy配置方式不同，特别是路径重写和 Cookie 的secure选项。

解决：仔细对照文档，测试所有接口。我们花了大半天才把所有代理规则调通。

坑 6：多页应用配置

我们的项目是多页应用（多个入口）。Webpack 用entry: { a: './src/a.tsx', b: './src/b.tsx' }，Vite 原生不支持多页。

解决：使用vite-plugin-html或手动配置build.rollupOptions.input：

build: {
  rollupOptions: {
    input: {
      a: resolve(__dirname, 'src/a.html'),
      b: resolve(__dirname, 'src/b.html')
    }
  }
}

坑 7：生产构建后路由 404

Vite 构建后，HTML 中的资源路径默认是绝对路径/assets/...，如果部署在子目录下会 404。

解决：设置base: './'（相对路径）或根据部署路径动态设置。

三、迁移后的收益

经过两周折腾，我们终于成功迁移。对比数据：

指标	Webpack	Vite	提升
开发服务器启动	45 秒	1.2 秒	37 倍
热更新时间（首次）	3 秒	0.1 秒	30 倍
生产构建时间	6 分 20 秒	1 分 50 秒	3.4 倍
配置文件行数	180 行	45 行	-75%
依赖安装大小	420MB	380MB	-10%

团队开发体验大幅提升，同事不再抱怨 “等编译”。

四、迁移建议

如果你也在考虑迁移，几点建议：

评估项目复杂度：如果项目大量使用 Webpack 特有插件（如DefinePlugin、ProvidePlugin），迁移成本高。
先跑 demo：拿一个最小模块试水，验证可行性。
渐进迁移：不用一次性全切，可以先用 Vite 开发，生产构建仍用 Webpack，逐步替换。
备好回滚方案：迁移期间保留原 Webpack 配置，出问题随时切回。
团队培训：Vite 的 HMR 机制、环境变量、动态导入与 Webpack 不同，团队要统一学习。

五、最后

Vite 不是银弹，但它确实解决了 Webpack 在开发体验上的痛点。如果你的项目也深受启动慢、热更新卡顿的困扰，不妨一试。

你们团队在用 Vite 吗？迁移中遇到过什么坑？点个赞让更多需要的人看到。

浏览器缓存最强攻略：强缓存、协商缓存、CDN、更新策略，一篇搞定

193577746 — Fri, 05 Jun 2026 20:31:04 +0800

网站加载慢？重复请求浪费带宽？用户总是看到旧版本？这些问题背后，都指向同一个关键词：缓存。今天我们从 HTTP 头开始，彻底搞懂强缓存、协商缓存、CDN 缓存、前端静态资源版本管理，以及最常见的缓存坑和解决方案。

一、缓存是什么？为什么重要？

缓存是 HTTP 协议中用于复用之前获取的资源的机制。合理使用缓存可以：

减少网络请求，页面加载更快
降低服务器压力
节省用户流量

但缓存用不好，会导致用户看到过期内容，或者每次都重新下载，失去缓存意义。

二、强缓存：服务器告诉浏览器 “别问了，直接用旧的”

强缓存由服务器返回的响应头中的 Cache-Control（HTTP/1.1）或 Expires（HTTP/1.0，已过时）控制。

2.1 Cache-Control 常用指令

指令	含义
`max-age=3600`	资源在 3600 秒内是 “新鲜的”，直接使用缓存，不请求服务器
`no-cache`	跳过强缓存，但可以用协商缓存（见下文）
`no-store`	完全不缓存，每次都重新下载
`public`	可以被任何中间节点（CDN、代理）缓存
`private`	只能被浏览器缓存，不能给中间节点（如用户个人信息）
`immutable`	资源永不变化（通常配合带 hash 的文件名使用），浏览器不必再验证

2.2 强缓存流程

浏览器请求资源 → 服务器返回资源 + Cache-Control: max-age=3600
→ 浏览器缓存该资源，3600秒内再次请求直接读缓存（200 from disk cache）
→ 3600秒后重新请求服务器

2.3 如何绕过强缓存？

刷新页面（F5 / Cmd+R）：浏览器会带上 Cache-Control: max-age=0，告诉服务器不要用缓存，走协商缓存。
硬刷新（Ctrl+F5 / Cmd+Shift+R）：浏览器带上 Cache-Control: no-cache，强制重新下载。

三、协商缓存：浏览器问服务器 “资源变了吗？”

当强缓存过期，或者请求头带有 Cache-Control: no-cache 时，浏览器会发起协商缓存请求，询问服务器资源是否有更新。

3.1 Last-Modified / If-Modified-Since

服务器返回 Last-Modified（资源最后修改时间），浏览器下次请求带上 If-Modified-Since。服务器比对时间，若未修改则返回 304 Not Modified，浏览器使用缓存；若修改则返回 200 和新资源。

缺点：

时间精度为秒，如果文件在 1 秒内多次修改，可能无法检测到。
如果文件内容没变但时间变了（如 CI 重新生成），也会导致重新下载。

3.2 ETag / If-None-Match（推荐）

ETag 是服务器根据文件内容生成的唯一标识（哈希值），更精确。浏览器下次请求带上 If-None-Match: "某hash"。若未变则返回 304，否则返回 200 和新资源。

优先级：ETag 高于 Last-Modified。

3.3 协商缓存流程

浏览器: 我有个资源，ETag是"abc"，你变了没？
服务器: 没变，304，你继续用旧的
浏览器: （用缓存）

四、强缓存 vs 协商缓存对比

特性	强缓存	协商缓存
发起请求	不发（直接用缓存）	发，但服务端不返回体
状态码	200 (from disk/memory cache)	304
控制头	Cache-Control / Expires	Last-Modified / ETag
适用场景	不常变的静态资源（JS/CSS/图片）	可能变化的 HTML、API 响应

五、最佳实践：如何配置？

5.1 静态资源（JS/CSS/图片）：强缓存 + 文件名 hash

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

注意：文件名必须带 hash（如 main.a3f2b1c.js），内容变化时 hash 变化，浏览器才会重新下载。这是目前最主流的前端静态资源缓存策略。

5.2 HTML 文件：协商缓存或 no-cache

location ~ \.html$ {
    add_header Cache-Control "no-cache";
}

因为 HTML 需要随时更新（入口文件），不能强缓存。

5.3 API 响应：按需

动态数据：Cache-Control: no-cache
相对固定的数据（如配置）：Cache-Control: max-age=60（短时缓存）

六、前端更新痛点与解决方案

问题：用户看到旧版本

常见于：

部署新版本后，用户浏览器缓存的旧 CSS/JS 未更新，导致页面错乱。
入口 HTML 被强缓存，用户没拿到新版本入口，自然不会请求新资源。

解决方案：

HTML 文件用协商缓存或短时缓存（如 max-age=60）。
静态资源用文件名 hash + 强缓存。
通过构建工具（Webpack/Vite）自动生成带 hash 的文件名。
部署时先上静态资源，后上 HTML。确保 HTML 引用的是最新的资源 hash。
可选项：在 HTML 中插入版本号或 query string（不推荐，因为可能被代理忽略）。

七、CDN 缓存

CDN 是 “反向代理缓存”，缓存静态资源在全球边缘节点。配置时需注意：

通过 Cache-Control: public 允许 CDN 缓存。
设置合适的 max-age，太短会增加回源请求，太长会导致更新不及时。
刷新 CDN 缓存通常需要手动调用 API 或版本化 URL。

八、调试缓存

Chrome DevTools：

Network 面板：Size 列显示 (memory cache)、(disk cache) 或状态码 304。
Disable cache 复选框：临时禁止缓存（仅限 DevTools 开启时）。
Application → Cache Storage：查看 Service Worker 缓存。
Clear site data：清除当前网站的缓存。

常用命令：

硬刷新：Cmd+Shift+R (Mac) / Ctrl+F5 (Windows)
清除缓存并硬刷新：打开 DevTools 后右键刷新按钮选择 “Empty Cache and Hard Reload”

九、常见坑点

坑	原因	解决
上线后用户还是旧版本	HTML 被强缓存	HTML 用 no-cache 或短时缓存
CSS 改了，页面样式还是旧的	CSS 文件名没变，浏览器强缓存	文件名加 hash
图片更新了，还是旧图	CDN 缓存未刷新	版本化 URL 或主动刷新 CDN
304 请求多，还是慢	强缓存没开，每次都协商	给静态资源加 max-age

十、总结

场景	推荐配置
静态资源（带 hash）	`Cache-Control: max-age=31536000, immutable`
HTML 入口	`Cache-Control: no-cache`
API（不变数据）	`Cache-Control: max-age=60`
API（动态）	`Cache-Control: no-cache`
用户头像等私有资源	`Cache-Control: private, max-age=3600`

缓存策略没有 “标准答案”，需要根据业务需求权衡实时性和性能。但记住：带 hash 的静态资源放心强缓存，入口文件绝不强缓存。

Charles 抓包工具从入门到实战

193577746 — Thu, 04 Jun 2026 12:08:51 +0800

你是否遇到过这些场景：线上接口返回异常但 DevTools 看不到？想把线上请求映射到本地调试？手机 App 的网络请求怎么抓？

如果你和我一样，对"代理"、"抓包"、"SSL 证书"这些概念一知半解，这篇文章帮你彻底搞懂。

Charles 是什么？

一句话：Charles 是一个 HTTP/HTTPS 代理服务器，能拦截并展示你电脑/手机上所有的网络请求和响应。

你可以把它理解成"网络请求的监控摄像头" — 所有进出你设备的流量都经过它，它全部记录下来给你看，还能让你中途修改。

工作原理 — 看完就懂

HTTP 请求：天然透明

HTTP 是明文传输的，Charles 作为中间人，直接就能看到所有内容：

浏览器 ── 请求 ──▶ Charles（看到并记录）── 请求 ──▶ 服务器
浏览器 ◀── 响应 ── Charles（看到并记录）◀── 响应 ── 服务器

不需要任何额外配置，打开 Charles 就能看到所有 HTTP 请求的完整信息。

HTTPS 请求：加密隧道

HTTPS = HTTP + TLS 加密。浏览器和服务器之间建立了加密隧道，Charles 虽然转发了数据，但只能看到"谁连了谁"，看不到具体内容。

这就是你在 Charles 里看到某些请求只显示 CONNECT 和一个 🔒 锁图标的原因 — Charles 知道你访问了 https://example.com，但不知道你请求了什么、服务器返回了什么。

SSL Proxying：Charles 的"双面间谍"模式

为了看到 HTTPS 的内容，Charles 需要开启 SSL Proxying，这时它会变成双面间谍：

                    ┌─────────────────────────┐
浏览器 ──TLS加密──▶ │  Charles（持有假证书）     │ ──TLS加密──▶ 真实服务器
                    │  ① 用假证书冒充服务器      │
                    │  ② 解密浏览器发来的请求     │
                    │  ③ 用真证书访问真实服务器    │
                    │  ④ 解密服务器返回的响应     │
                    │  ⑤ 再用假证书加密返回浏览器  │
                    └─────────────────────────┘

整个过程：

浏览器发起 HTTPS 请求到 https://api.example.com
Charles 拦截，伪造一张 api.example.com 的证书返回给浏览器
浏览器以为在和真正的服务器通信，把请求用"假证书"加密发给 Charles
Charles 解密请求，看到明文内容并记录
Charles 再用真正的证书和 api.example.com 建立连接，把请求转发过去
拿到真实响应后，Charles 解密、记录，再用假证书加密返回给浏览器

浏览器全程被蒙在鼓里。

为什么需要安装 Charles 根证书？

浏览器不是傻子。正常情况下，收到一张"假证书"会立刻报错：NET::ERR_CERT_AUTHORITY_INVALID。

安装 Charles 根证书的意思是：告诉系统"我信任 Charles 签发的所有证书"。这样浏览器收到 Charles 伪造的证书时就不会报警了。

`*:443` 通配符为什么会搞坏某些网站？

在 SSL Proxying Settings 里配了 *:443 后，Charles 会对所有 HTTPS 流量执行中间人解密。大部分情况下没问题，但有几种例外：

情况	原因
证书钉扎（Certificate Pinning）	某些 App/网站会硬编码真实证书的指纹，发现不是原证书就拒绝连接
HSTS Preload	浏览器内置了某些域名的证书规则，不接受非官方 CA 签发的证书
双向认证（mTLS）	服务器要求客户端也出示证书，Charles 无法提供
系统级请求	macOS 推送通知、iCloud 同步等系统服务被代理后可能异常

SSL Proxying 的正确配置姿势

❌ 错误做法：只配特定域名

Include: my-api.com:443

问题：其他所有 HTTPS 请求都只能看到 CONNECT 隧道，看不到内容。抓包功能大打折扣。

❌ 错误做法：`*:443` 通配符 + 不管 Exclude

Include: *:443
Exclude: （空）

问题：所有 HTTPS 流量都被解密，可能导致某些网站/App 访问异常。

✅ 推荐做法：`*:443` 通配符 + Exclude 排除问题域名

Include: *:443
Exclude: problematic-site.com:443
         some-pinned-app.com:443

默认能看到所有 HTTPS 内容，遇到哪个网站因 Charles 挂掉了，就加到 Exclude 里。这是最省心的方案。

前端最常用的 6 个功能

1. 抓包查看请求详情

最基础的功能。打开 Charles → 访问页面 → 左侧 Structure 列表找到目标域名 → 点击具体请求。

Request 标签：请求头、请求参数、请求体
Response 标签：响应头、响应体（JSON / HTML / 图片）
Overview 标签：URL、状态码、耗时、请求大小

实际场景：后端说"接口没问题"，你觉得前端也没问题。Charles 一抓包，发现请求参数少传了一个字段 — 破案。

2. Map Remote（远程映射）⭐

把线上/测试环境的请求映射到本地开发服务器，这是前端最高频使用的功能。

线上请求：https://cdn.example.com/app/index.js
映射到：  http://127.0.0.1:3000/index.js

配置方式：Tools → Map Remote → Add

字段	From（线上）	To（本地）
Protocol	https	http
Host	cdn.example.com	127.0.0.1
Port	443	3000
Path	/app/*	/*

使用场景：

在线上/测试环境调试本地代码
不用发布就能在真实环境验证修改
搭建平台组件本地预览

⚠️ 如果 From 是 HTTPS，必须在 SSL Proxying 的 Include 中添加该域名！否则 Map Remote 不生效。

3. Map Local（本地文件映射，我愿称之为：本地开发的神！！！）

用本地文件替换接口返回，非常适合 Mock 数据。

请求 https://api.example.com/user/info
→ 返回本地文件 ~/mock/user-info.json

配置方式：Tools → Map Local → Add

使用场景：

后端接口还没开发好，前端先用 Mock 数据开发
复现某个特定的接口返回场景（如错误码、空数据）
不用改前端代码就能切换不同的数据

4. Rewrite（重写请求/响应）

修改请求或响应的 Header、Body、URL 等。

配置方式：Tools → Rewrite → Add

场景	做法
解决跨域	修改 Response Header，添加 `Access-Control-Allow-Origin: *`
修改 Cookie	修改 Request Header 的 `Cookie` 字段
模拟接口超时	修改 Response Status 为 `504`
注入调试参数	修改 Request URL 的 Query 参数

5. Breakpoints（断点）

拦截请求或响应，手动编辑后再放行。类似 Debugger，但是针对网络请求。

使用方式：右键请求 → Breakpoints → 再次发送该请求时会被拦截

使用场景：

手动修改请求参数后再发送
修改接口返回数据后再给到前端
模拟各种异常场景

6. Throttle（限速）

模拟弱网环境，测试页面在慢网下的表现。

配置方式：Proxy → Throttle Settings → 勾选 Enable Throttling → 选择预设或自定义

预设	下载速度	延迟
3G	780 Kbps	200ms
4G	6 Mbps	50ms
WiFi	30 Mbps	2ms

完整安装与配置教程

第一步：安装 Charles

前往 Charles 官网下载安装。

第二步：安装根证书（关键！）

macOS

菜单 Help → SSL Proxying → Install Charles Root Certificate
钥匙串访问自动打开，找到 Charles Proxy CA 证书
双击证书 → 信任 → 选择 「始终信任」
关闭窗口，输入密码确认

Windows

菜单 Help → SSL Proxying → Install Charles Root Certificate
按提示安装到「受信任的根证书颁发机构」

第三步：配置 SSL Proxying

菜单 Proxy → SSL Proxying Settings
勾选 Enable SSL Proxying
Include 列表点 Add，Host 填 *，Port 填 443
后续遇到问题域名加到 Exclude 列表

第四步（可选）：手机抓包

iOS

手机和电脑连同一个 Wi-Fi
手机设置 → Wi-Fi → 当前网络 → HTTP 代理 → 手动
- 服务器：电脑 IP（Charles 菜单 Help → Local IP Address 查看）
- 端口：8888
手机 Safari 打开 chls.pro/ssl 下载并安装描述文件
设置 → 通用 → 关于本机 → 证书信任设置 → 打开 Charles 证书信任开关

Android

基本步骤与 iOS 相同，但 Android 7.0+ 默认不信任用户安装的 CA 证书。解决方案：

如果是自己的 App：在 AndroidManifest.xml 中配置 networkSecurityConfig 信任用户证书
如果是第三方 App：需要 Root 设备将证书安装到系统目录

常见问题 FAQ

Q: 为什么某些请求只显示 CONNECT 看不到内容？

这些是 HTTPS 请求，且该域名未被 SSL Proxying 解密。确认 SSL Proxying 的 Include 列表中包含该域名（或通配符 *:443）。

Q: 开了 Charles 后某些网站打不开？

该网站的证书被 Charles 代理后出了问题。两种解决方式：

把该域名加到 SSL Proxying 的 Exclude 列表
暂时关闭 SSL Proxying（菜单 Proxy → 取消勾选 SSL Proxying）

Q: Map Remote 配了但不生效？

排查清单：

☑️ Map Remote 是否启用（Enable Map Remote 要勾选）
☑️ From 的协议、Host、Path 是否完全匹配实际请求
☑️ 如果 From 是 HTTPS，SSL Proxying 是否包含了该域名
☑️ 本地服务是否启动且端口正确
☑️ Charles 是否在录制状态（顶部红色录制按钮应为激活态）

Q: 关了 Charles 后上不了网？

Charles 修改了系统代理设置但没正常还原。手动关闭：

macOS：系统设置 → 网络 → Wi-Fi → 详细信息 → 代理 → 关闭所有代理
Windows：设置 → 网络和 Internet → 代理 → 关闭手动代理

Q: 如何只看某个域名的请求？

三种方式：

左下角 Filter 输入框输入域名关键词
右键域名 → Focus — 只高亮显示该域名
菜单 Proxy → Recording Settings → Include 只录制特定域名

快捷键速查表

操作	macOS	Windows
开始/停止录制	`⌘ R`	`Ctrl + R`
清空会话	`⌘ K`	`Ctrl + K`
重放选中请求	`⌘ R`	`Ctrl + R`
搜索请求	`⌘ F`	`Ctrl + F`

总结

概念	一句话理解
Charles	网络请求的监控摄像头 + 编辑器
代理	浏览器把请求托管给 Charles，Charles 帮忙转发
SSL Proxying	Charles 伪造证书做中间人，解密 HTTPS 流量
根证书	让系统信任 Charles 的"假证书"，否则浏览器会报错
Map Remote	把线上请求指向本地服务器
Map Local	用本地文件替换接口返回
Rewrite	修改请求/响应的 Header、Body
Breakpoints	拦截请求/响应，手动编辑后放行

SSL Proxying 推荐配置：Include 保留 *:443，遇到问题域名加到 Exclude。

掌握以上内容，日常前端开发中 90% 的抓包和代理调试需求都能搞定 🎉

如果这篇文章对你有帮助，欢迎点赞收藏 ❤️

开源｜Image Harvest v1.0.5：AI 智能标签 + Eagle 导出，设计师和开发者的图片工作流神器

193577746 — Wed, 03 Jun 2026 20:05:22 +0800

大家好，我是 Image Harvest 的作者。今天发布 v1.0.5 大版本更新，主要面向设计师和前端开发者的图片工作流优化。

🆕 核心新功能

1. AI 智能标签

基于 AI 视觉模型，一键为图片生成 photo / illustration / icon / ui 等描述性标签
标签跨会话持久化，可在筛选器中按标签过滤
支持批量打标：选中多张图片，一键全部标注

2. Eagle 素材导出

一键将选中图片导出到 Eagle 素材管理器
AI 标签自动同步到 Eagle（打完标再导出 → Eagle 中直接带标签）
支持来源 URL、文件名等元数据传递

3. 批量操作工具栏

底部新增：批量收藏 | 批量 AI 标签 | 批量删除
选中图片后直接操作，无需逐个点击
收藏支持 URL 去重，不会重复添加

🎯 适用场景

UI 设计师：从 Dribbble/Behance 批量抓参考图 → AI 打标 → 导出 Eagle
前端开发：批量下载页面素材，按格式/尺寸筛选
电商运营：竞品图片采集 + 相似检测去重
内容创作者：博客配图批量获取

📦 安装

Chrome Web Store

插件官网

Github

大厂面试新规：不会用 AI 编程，直接挂

193577746 — Tue, 02 Jun 2026 18:40:40 +0800

面试官笑呵呵地抛出第一题：“你们谁用过 Copilot 或者 Cursor？说说怎么用 AI 生成一个带状态管理的 React 组件？” 七个人，六个低下了头。剩下那个举手说 “我用过 ChatGPT 写代码”，面试官追问 “那你有没有自己封装过 LLM 的 API 调用？有没有做过流式输出的性能优化？”——举手的人也沉默了。全场死寂。连键盘声都没了。

2026 年的前端面试，变了

这不是段子。这是 2026 年春招，某二线大厂前端群面的真实场景。

曾几何时，我们以为背熟 ES6、刷透 LeetCode、手写 Promise、精通 Vue 和 React 的源码，就能稳拿 offer。现在呢？面试官开口闭口就是：

“你如何在浏览器端调用大模型 API？token 消耗怎么优化？”
“前端怎么实现 RAG 的文档检索？向量数据库你用过哪个？”
“有没有用 Web Worker 跑过轻量级模型？ONNX Runtime 了解吗？”
“AI 辅助编程工具用得多吗？你怎么保证生成代码的质量和安全？”

每一个问题，都像一把刀，精准地扎在普通前端的知识盲区上。

更狠的是，面试官自己也承认：“其实这些题，我们内部也没几个人能完全答上来。但老板说了，今年招人必须要有 AI 素养——不会用 AI 写代码、不懂 AI 产品落地的，一律不要。”

我身边真实的 “AI 面试惨案”

我认识一个 28 岁的帅小伙，三年前端经验，项目写得漂漂亮亮。今年跳槽，面了 7 家公司，5 家挂在 AI 题上。有一家技术负责人很直接：“你业务能力没问题，但我们希望前端能主动用 AI 提效，甚至参与到 AI 产品的落地里。你不懂这些，来了也是拖后腿。”

拖后腿。这三个字，像一记耳光。

他还算年轻的。那些 35+、拖家带口、学新东西明显吃力的老前端呢？他们连面试机会都拿不到——简历上没写 “AI 相关经验”，HR 那一关就直接筛掉了。

群面七人沉默的那个场景，我反复想了很多遍。如果我是那七个中的一个，我会不会也低下头？

面试官到底在考什么？

2026 年的前端面试逻辑已经完全变了。

以前考你 “能不能写”——手撕算法、手写框架、默写八股文。现在考你 “会不会管”——拆解需求、指挥 AI、审查产出、做技术决策。

阿里 2026 暑期 AI 实习岗明确要求 “AI 编程工具（如 Cursor、Claude Code）的极致依赖”，以及 “工程化落地能力” 在招聘中的核心地位。警示纯理论研究者及传统编码者的风险——简历里若缺乏可展示的项目级 AI 实践经验，“在简历筛选阶段极易被直接淘汰”。

字节 2026 年春招的 “测试开发工程师 - 开发者 AI” 岗位，直接硬性要求对 AI Agent 有深入理解和实践经验。阿里 “通义实验室 - 技术专家 - 测试开发” 也明确要求 “熟练掌握机器学习算法原理”。

不只是在 JD 上喊口号，面试里已经在真刀真枪地考了。2026 年大厂面试题汇总里，“AI 辅助编程” 已经作为独立的面试新趋势被列出来。

但 AI 面试官自己也很 “虚”

讽刺的是，AI 面试官自己也在被吐槽。有面试官坦言：“其实这些 AI 题，我们内部也没几个人能完全答上来。但老板说了，今年招人必须要有 AI 素养——不会用 AI 写代码、不懂 AI 产品落地的，一律不要。”

技术圈对这种新规也争议很大。一部分人认为这是与时俱进——84% 的全球开发者已经使用或计划使用 AI 编程工具，企业招人当然要优先考虑会用 AI 的人。另一部分人则批判这是 “跟风式焦虑”——面试官自己都没搞明白，凭什么要求候选人懂？

一位资深面试官在反思文章里写：“当一个人的 ‘知识库’ 和 ‘经验’ 都可以被 AI 低成本伪造时，我们曾经引以为傲的面试体系，正在面临系统性失效的风险。AI 时代，工程师最稀缺的能力，恰恰是那些非技术的东西。”

话说回来，AI 不是来取代你的

现在很多人对 “懂 AI” 的理解极其肤浅。以为在项目里接个 OpenAI 或者 Claude 的接口，搞个对话框，把输入框的字传过去，把返回的字用 Markdown 渲染出来，就叫 AI 前端工程师了。那不叫 AI 开发，那叫表单提交。

大模型时代，前端真正的难点根本不是发送请求，而是应对大模型带来的复杂性——不可控的输出、流式传输的残缺 JSON、工具调用的中间状态、安全风险的审查。

我身边有一个靠 AI 面试成功的人。他拿到的 offer，面试题不是手写代码，而是 “带着电脑，现场用 Cursor 完成一个功能”。他不仅生成了代码，还在面试官面前改了需求、调优了性能、排查了 AI 生成的 bug。面试官当场说：“这就是我们要的人。”

如果你现在还在找工作，几点不成熟的建议

至少准备 2-3 个 “AI+ 前端” 的实战故事——不能只说 “我用过 Cursor”，要说清楚在什么场景下、怎么拆解需求、怎么给 AI 指令、AI 犯了什么错、你怎么纠正的。

练代码审查比练写代码更重要——AI 能写出 80% 对的代码，但那 20% 的错误往往是最致命的。你的价值不在于写得比 AI 快，而在于能发现 AI 发现不了的问题。

别只会调用 API——真实的高阶 AI 前端工程，每天面对的是流式渲染、复杂状态机、AST 解析、沙盒隔离。把这些底子打好，比背一百个 Prompt 模板有用。

写在最后

2026 年的前端面试，AI 早已不是 “加分项”，而是像 HTML、CSS 一样的基础 “必考项”。这背后折射出的，是整个行业环境的剧变——AI 已经渗透到了业务的每一个角落。

你以为面试官在考 AI，其实他们在考你——在工具越来越强的时代，你还有多少不可替代的东西。

AI 生成代码快如闪电，但我修了三个小时——它到底帮了谁？

193577746 — Mon, 01 Jun 2026 18:59:38 +0800

上周，老板丢过来一个内部后台页面的需求，说 “不急，明天给就行”。我打开 v0，输入 “帮我生成一个用户管理后台，包含表格、筛选、分页、编辑弹窗”。一分钟，页面出来了。表格、按钮、弹窗、样式，一应俱全。我复制代码到项目里，跑起来，看起来没问题。然后接下来三个小时，我都在改它的代码。

一、“神速” 生成，然后呢？

v0 生成的速度确实快。但当我开始真正 “使用” 这份代码时，问题一个接一个冒出来：

变量名随心所欲：data、items、itemData、filteredData……一个表格数据，四五个名字来回用。改一个地方，全局搜索半天。
样式写死：按钮宽度固定 120px，手机上看溢出；表格列宽固定，屏幕一缩就横向滚动。没有响应式，没有移动端适配。
状态管理混乱：筛选条件、分页、弹窗开关全部挤在同一个 useState 里，改一个导致别的组件无辜重渲染。
没有错误处理：接口返回 null，页面直接白屏。没有 loading，没有空状态。

这些不是 bug，是 “能用但没法维护”。

二、修了三个小时，改了啥？

我花时间做的事，恰恰是 AI 最不擅长的事：

重命名所有变量，让代码能读。
把固定宽度改成 flex + 百分比，加媒体查询。
拆分状态，用 useReducer 管理筛选和分页。
补上 loading、错误提示、空数据占位。

说实话，到最后我有点怀疑：如果我自己从头写，可能也就三个半小时。AI 帮我省了半小时，但我额外付出了 “读懂它逻辑” 的成本。这笔账，算不过来。

三、AI 到底帮了谁？

我知道，会有人说 “你不会写 prompt”“你不会调教”。也许更精确的 prompt 能生成更好的代码。但问题是，AI 生成的代码像一辆组装好的车，看起来能跑，但一上路就发现螺丝没拧紧，轮胎是歪的。它不是不能开，而是你需要先花时间检查所有零件。

对于不熟悉项目上下文、不知道团队规范、不了解业务细节的 AI 来说，生成 “能跑” 的代码已经是极限。而 “可维护” 的代码，恰恰需要这些信息。

所以，AI 到底帮了谁？帮我省了半小时打字时间？还是帮老板更快地看到 “可视的进度”？对于开发者自己，短期 “快” 的背后，是长期的 “改”。

四、我现在怎么用 AI？

我没有放弃 AI，而是调整了用法：

不用 AI 写核心业务逻辑：自己设计状态和接口，用 AI 生成工具函数或数据 mock。
用 AI 写文档和注释：生成 JSDoc、README、测试用例，这些不会坑人。
AI 生成代码后，强制做一轮重构：重命名、拆分、补异常，把 “能跑” 变成 “能维护”。

这样一来，AI 节省的时间，不会在改代码时加倍吐回去。

五、最后

AI 写代码快，但不是免费的。你省下的打字时间，很可能变成修代码的时间。这笔账，建议每个团队都算清楚。

微软用 Go 重写 TypeScript 编译器，速度提升 10 倍，网友：这是 “背叛” 还是 “救赎”？

193577746 — Sun, 31 May 2026 23:10:01 +0800

4 月 22 日，微软宣布 TypeScript 7.0 Beta 正式发布。这一次，TypeScript 团队干了一件让整个 JS 社区炸锅的事——他们把编译器和工具栈，从 TypeScript/JavaScript 底层完全移植到了 Go。速度通常比 6.0 快约 10 倍。编译 VS Code 代码库从 78 秒缩到 7.5 秒。消息一出，有人叫好，有人愤怒，更多人在问：TypeScript 这是 “背叛” JavaScript 了吗？

一、发生了什么？

年初，微软官宣了一个叫 “Project Corsa” 的计划：用 Go 语言，重写整个 TypeScript 编译器。不是 TypeScript，不是 Rust，是 Go。重写之后，编译速度预计提升10 倍。

4 月 22 日，微软正式发布 TypeScript 7.0 Beta。在过去的近一年中，微软开发者将现有的 TypeScript 代码库从 TypeScript（作为编译成 JavaScript 的引导代码库）移植到了 Go。通过结合原生代码速度和共享内存并行性，TypeScript 7.0 的速度通常比 TypeScript 6.0 快约 10 倍。

二、为什么有人 “吵翻了”？

消息一出，社区立刻分裂。支持派说：“终于！大型项目编译几分钟的时代，终于要结束了。”反对派说：“TypeScript 自己都是用 TypeScript 写的，这是灵魂。用 Go 重写？这是 ‘背叛’。”

最大的争议点：为什么选 Go，而不是 Rust？ 这是问得最多的问题。微软给出的解释包括：Go 的编程风格与现有 TypeScript 代码库高度相似，移植更容易；goroutine原生支持并行类型检查；垃圾回收针对这种超大量小对象的编译器场景优化得很好；TypeScript 团队已有 Go 经验。

三、一个细节：为啥 TypeScript 6.0 比 7.0 更早发布？

微软实际上是在 TypeScript 6.0 发布前就启动了 Go 重写计划。他们把 6.0 定位为 “基于 JS 编译器的最后一个版本”，所以 7.0 才是真正的 Go 重写版。

四、实际体验：真的能快 10 倍吗？

微软自家的 VS Code 代码库约 150 万行 TypeScript，旧编译器编译约 78 秒，新tsgo只用了 7.5 秒，快 10.4 倍。Playwright 和 TypeORM 等项目也报告了约 10-13 倍的性能提升。

在编辑器方面，导入补全、快速跳转、查找所有引用的响应时间也大幅缩短，内存使用量约为旧版的一半。

五、兼容性：需要改代码吗？

官方强调新的 Go 代码库是从现有实现中系统性移植而来，类型检查逻辑与 TypeScript 6.0 完全一致，不需要为新编译器重构代码。新tsgo命令行工具与旧tsc参数行为完全兼容。

六、试用：今天就能用

目前通过@typescript/native-preview包名安装，命令行入口是tsgo。官方表示稳定的程序化 API 预计要到 7.1 版本。

七、最后

TypeScript 团队用 Go 重写编译器，让大型项目编译从 “喝杯咖啡” 变成 “眨个眼”。有人解读为 “背叛”，但也许更像一次务实的 “脱胎换骨”。

你愿意现在就装个 Beta 版试试吗？10 倍速，值得一试。

八、代码块：立刻体验

# 在现有项目中安装 TS 7.0 Beta
npm install -D @typescript/native-preview@beta

# 使用新编译器检查类型（体验10倍速度）
npx tsgo --noEmit

你会为了 10 倍速尝鲜 Beta 版吗？评论区聊聊你的选择。点个赞让我看到有多少人已经换上了。

面试 8 家前端岗位后，我发现了一个残酷的事实：AI 不是加分项，是门槛

193577746 — Sat, 30 May 2026 15:01:41 +0800

上个月，我集中面试了 8 家公司的前端岗位，有大厂、有中厂、也有创业公司。投简历、刷题、背八股、跑现场……一套流程走下来，最让我意外的不是算法题的难度，而是——每一家都问了同一个问题：“你平时用 AI 编程工具吗？” 不是随口一问，是认真地问：用的什么？怎么用的？有没有具体的提效案例？有一家甚至让我现场打开 Cursor，写一个组件。我突然意识到：AI 已经不是加分项了，它正在变成门槛。

一、面试官的 “新标配问题”

8 场面试，所有面试官都问了 AI 工具相关的问题。我把它们分成三类：

第一类：基础使用题

“你平时用 Copilot 还是 Cursor？”
“大概用多久了？感觉怎么样？” 这种问题比较温和，像在确认你 “跟上了时代”。

第二类：场景应用题

“你用 AI 做过 Code Review 吗？效果如何？”
“有没有遇到 AI 生成的代码有坑的情况？” 这类问题已经开始考察你的实际经验和判断力。

第三类：现场实操题

“打开你的编辑器，用 AI 写一个带防抖的搜索组件。”
“这段 AI 生成的代码有明显 bug，你能找出来吗？” 这类问题最狠。面试官不是在考你背不背得出代码，而是考你会不会审查和优化 AI 写的代码。

二、一位面试官的原话

有一场面试，面试官看了我的简历后说：“我们团队现在重度依赖 Cursor，写代码的效率确实高。但我们也发现，AI 写的代码容易出边界问题、性能隐患。我们要的不是只会敲回车的人，而是能看懂 AI 代码、能发现问题的人。”

他说：“你面试通过后，入职第一周的任务就是熟悉我们的 AI 辅助开发规范——哪些场景可以用 AI，哪些必须手写，怎么 review AI 生成的 PR。”

三、我的感受：不是恐慌，是压力

说实话，我并不恐慌。我会用 AI，也知道怎么用好它。但压力是真实的：这意味着我要额外花时间研究 AI 编程工具的最佳实践、学习如何引导 AI 生成高质量代码、培养自己 review AI 代码的能力。以前面试只要会算法、会框架、会系统设计。现在还要再加一门课：AI 辅助开发实战。

而且这个领域变化很快。去年还在问 “你听说过 Copilot 吗”，今年已经问 “你用 AI 重构过屎山吗”。明年会问什么？我不敢想。

四、给同行的建议（也是给自己的）

如果你还没有系统性地使用 AI 编程工具，建议尽快补上。可以从这几方面入手：

选择一个主力工具：Cursor 或 Copilot，至少用熟一个。
学习写 Prompt：不要只让 AI 生成 “一个函数”，要给出清晰的输入输出、边界条件、性能要求。
重视 review 能力：遇到 AI 生成的代码，多问自己 “这段代码哪里可能出问题”。
积累失败案例：面试时讲一个 “AI 生成的 bug 被你发现并修复” 的故事，比单纯说我用了 AI 更有说服力。

五、最后

这不是贩卖焦虑，而是描述事实：2026 年的前端面试，AI 工具使用能力已经成为一道必答题。

14MB VS 15KB：前 React 核心成员用 AI 写了个排版库，让 Safari 快了一千倍

193577746 — Fri, 29 May 2026 12:14:19 +0800

前 React 核心成员 Cheng Lou 在推特上甩了一个链接：“我写了一个 15KB 的排版引擎，叫 Pretext。” 配图是一段文字绕着不规则形状流动的视频。评论区炸了：“这效果以前只能用 canvas 画，性能还稀烂。”“怎么做到的？” 第二天，项目 GitHub 星数破万。第三天，破两万八。一周内，Hacker News、Reddit、Twitter 全在讨论。一个 15KB 的库，怎么就让整个前端圈沸腾了？

一、故事的起点：前 React 核心成员的 “业余项目”

Cheng Lou，这个名字在 React 早期社区很响亮。他贡献过核心代码，也做过著名的 “时间旅行” 演讲。后来他淡出了主流视野。大家都以为他在享受生活。结果他憋出一个大招：一个 15KB 的排版引擎。

为什么这件事让社区这么兴奋？因为排版——文字如何换行、环绕、对齐——是浏览器三十年来的 “硬骨头”。你滚动页面、调整窗口大小、打开一个复杂布局的网页，背后都在进行昂贵的排版计算。浏览器用的方法是 “回流”：把文字放进 DOM 里，问浏览器 “你的宽度是多少？”，浏览器只好重新计算一遍布局，整个过程同步、阻塞、性能差。

二、传统排版为什么慢？

简单说，浏览器排版是一个 “黑盒”。你给它文字和宽度，它给你一个 “换行位置”。但这个计算过程是同步的，涉及到字形度量、上下文、连字等复杂因素。而且，每次你改变文字内容或容器大小，浏览器都要重新算一遍。这就是为什么复杂排版会卡。

三、Pretext 的思路：绕过 DOM，用数学计算

Pretext 的核心思想很简单：不在 DOM 里排版，在 Canvas 里算。它利用 Canvas API 直接测量文字宽度（measureText），然后用算法自己决定在哪里换行、在哪里对齐。这个过程不触发回流，不阻塞主线程。而且，它把计算结果缓存起来，相同的文字和容器宽度直接复用。

最惊人的是性能对比。Cheng Lou 在发布会上演示：同样的复杂排版，传统方法在 Safari 下耗时约 150ms，Pretext 只要 0.12ms，快了一千两百多倍。其他浏览器也快了数十到上百倍。

四、AI 的角色：不是写代码，是 “调参”

Pretext 的代码量不大，大部分逻辑是 Cheng Lou 自己写的。但他用 AI 做了一件更有趣的事：浏览器兼容性调试。不同操作系统、不同浏览器、不同字体下，measureText的返回值有微小差异。Cheng Lou 写了一个脚本，让 AI 自动在 Chrome、Safari、Firefox、Edge 的 Windows、macOS、Linux 版本上运行测试，收集了 7680 组数据，然后让 AI 分析差异并生成修正系数。他说：“如果没有 AI，这个项目可能要再花半年时间调参数。”

五、社区反应：从 “这能干啥” 到 “我也可以”

Pretext 发布后，社区很快分成了两派。质疑派说：“这只是个 demo，不能用在实际项目。” 支持派则开始疯狂创作：有人用它实现文字围绕任意形状（手绘的曲线、SVG 路径）；有人做了多栏杂志布局，滚动丝滑；还有人把 Pretext 嵌入到实时聊天室，每一条新消息都能动态重排，不掉帧。

最有趣的是一个开发者用它实现了一个 “流动的诗歌” 页面：文字像溪水一样沿着屏幕上的波浪线流动，鼠标拖动改变形状，文字实时重新排版。这在以前几乎不可想象。

六、对前端的意义：创新不只 AI

Pretext 的爆火，折射出 2026 年前端圈的一种情绪：大家有点腻了框架大战、AI 生成代码、效率工具。当 Cheng Lou 拿出一个 15KB、无依赖、硬核性能优化的库时，大家发现：前端还能这么玩。它不依赖 React、Vue、Svelte，不依赖 AI 生成页面，就是对底层能力的一次极致挖掘。

这也提醒我们：在 AI 能写出 80 分代码的时代，人类工程师的竞争力在哪里？可能是定义问题、设计算法、解决那些 AI 搞不定的极端情况。Cheng Lou 没被 AI 取代，反而用 AI 加速了自己独特想法的实现。

七、最后：你会用它吗？

Pretext 目前还不是生产级的方案，缺少滚动虚拟化、无障碍支持等。但它的思路已经启发了一批开发者。有人开始尝试把它集成到 Next.js 里，有人写了一个基于 Pretext 的 Markdown 渲染器。Cheng Lou 本人也表示，会持续维护，目标是成为一个真正可用的排版引擎。

至少，它让我们看到：浏览器还没被挖透，前端还有创造的空间。

手写虚拟 DOM 后，我反问面试官：key 为什么不能用 index？

193577746 — Thu, 28 May 2026 18:16:46 +0800

前言

虚拟 DOM 和 diff 算法是 React 面试的 “进阶题”，一般不会让手写完整实现，但一旦遇到，就是区分 “会用 React” 和 “懂 React” 的分水岭。大部分前端能说出虚拟 DOM 的好处，但真要写一个 mini 版，很多人会卡在 diff 的 key 逻辑上。

今天我就还原那次面试：AI 生成的虚拟 DOM 核心代码、我是如何解释 diff 的、以及为什么 “key 不能用 index” 这个问题能让我反客为主。最后附完整代码，你可以直接拿去跑，也可以用来准备面试。

一、AI 生成的虚拟 DOM 核心代码

我在 Cursor 里输入：

用原生 JavaScript 实现一个简易虚拟 DOM 库，包含：

h(type, props, ...children) 创建虚拟节点

render(vnode) 将虚拟节点转为真实 DOM

patch(oldVnode, newVnode) 对比并更新真实 DOM，支持 key 属性，实现最小化更新

AI 输出的核心结构如下（精简后）：

// 创建虚拟节点
function h(type, props, ...children) {
  return { type, props: props || {}, children: children.flat() };
}

// 渲染虚拟DOM到真实DOM
function render(vnode) {
  if (typeof vnode === 'string') return document.createTextNode(vnode);
  const el = document.createElement(vnode.type);
  for (let key in vnode.props) {
    el.setAttribute(key, vnode.props[key]);
  }
  vnode.children.forEach(child => el.appendChild(render(child)));
  return el;
}

// 简易diff（带key优化）
function patch(oldVnode, newVnode, parent = oldVnode.parentNode) {
  // 如果是文本节点
  if (typeof oldVnode === 'string' || typeof newVnode === 'string') {
    if (oldVnode !== newVnode) {
      parent.replaceChild(render(newVnode), oldVnode);
    }
    return;
  }
  // 不同类型，直接替换
  if (oldVnode.type !== newVnode.type) {
    parent.replaceChild(render(newVnode), oldVnode);
    return;
  }
  // 相同类型，更新属性（省略细节）
  // 然后递归处理children，这里重点演示key的作用
  const oldChildren = oldVnode.children;
  const newChildren = newVnode.children;
  const keyedOld = new Map();
  // 将旧节点按key建立索引
  oldChildren.forEach((child, idx) => {
    if (child.props && child.props.key) keyedOld.set(child.props.key, { child, idx });
  });
  // 遍历新节点，复用key相同的节点
  newChildren.forEach((newChild, newIdx) => {
    if (newChild.props && newChild.props.key) {
      const matched = keyedOld.get(newChild.props.key);
      if (matched) {
        // 复用该DOM节点，递归更新子内容
        patch(matched.child, newChild, parent);
        // 移动位置（这里省略，示意核心）
        return;
      }
    }
    // 没有匹配，插入新节点
    parent.appendChild(render(newChild));
  });
}

二、我反问了面试官一个问题

等代码展示完，面试官还没开口，我说：“这个 diff 算法里用 key 来匹配节点。很多前端都用过 key，但有一个经典误区——把数组索引当 key 用。您知道为什么这样会有问题吗？”

他来了兴趣：“你说说看。”

我解释：

diff 算法通过 key 判断节点是否 “相同”。如果用索引，比如列表顺序变了，索引 0 可能原来对应 A，现在对应 B，但 key 相同（都是 0），React 会认为这两个节点相同，不重新创建，只是更新内容。这样本应销毁 A、创建 B 的场景，变成了复用 A 并修改内容。如果组件有复杂状态（比如动画、输入框焦点），就会出现状态错乱。
更严重的是，在列表头部插入一个元素，所有后续节点的索引都变了，每个节点都会被 “原地修改”，性能反而比不用 key 还差。
正确做法是用数据中唯一稳定的标识（如 id）作为 key。

他点头：“这才是我想听到的答案。”

三、为什么面试官认可这种 “反客为主”？

他后来告诉我：“你能自己生成正确的 diff 逻辑，还能主动抛出常见的误区，说明你不仅会写，还真的思考过生产中的坑。这种深度，比背代码有价值。”

所以这道题的关键不是完美写出所有 diff 逻辑，而是理解 key 的真实作用。AI 帮你搭了骨架，你用自己的理解填充了灵魂。

四、完整可运行的迷你虚拟 DOM 代码

我把面试中使用的完整代码放在这里，你可以在浏览器控制台运行测试：

// 完整示例（带简版diff和key复用）
function h(type, props, ...children) {
  return { type, props: props || {}, children: children.flat() };
}
function render(vnode) {
  if (typeof vnode === 'string') return document.createTextNode(vnode);
  const el = document.createElement(vnode.type);
  for (let k in vnode.props) el.setAttribute(k, vnode.props[k]);
  vnode.children.forEach(c => el.appendChild(render(c)));
  return el;
}
function patch(oldVnode, newVnode, parent = oldVnode.parentNode) {
  if (oldVnode === newVnode) return;
  // 文本节点
  if (typeof oldVnode === 'string' || typeof newVnode === 'string') {
    if (oldVnode !== newVnode) parent.replaceChild(render(newVnode), oldVnode);
    return;
  }
  if (oldVnode.type !== newVnode.type) {
    parent.replaceChild(render(newVnode), oldVnode);
    return;
  }
  // 更新属性（略）
  // 处理children（简易版：只演示替换，不移动）
  const oldChildren = oldVnode.children;
  const newChildren = newVnode.children;
  const maxLen = Math.max(oldChildren.length, newChildren.length);
  for (let i = 0; i < maxLen; i++) {
    if (i < oldChildren.length && i < newChildren.length) {
      patch(oldChildren[i], newChildren[i], parent.childNodes[i]);
    } else if (i < newChildren.length) {
      parent.appendChild(render(newChildren[i]));
    } else {
      parent.removeChild(parent.childNodes[i]);
    }
  }
}

你可以用这段代码测试列表渲染，尝试改变顺序或插入头节点，观察不用 key vs 用 index vs 用 id 的区别。

五、写在最后

虚拟 DOM 和 diff 是 React 的根基，手写一遍能让你对性能优化有更深的体感。AI 能帮你快速生成模板，但真正拉开差距的，是对 “为什么 key 不能用 index” 这种问题的思考深度。

推行 AI 写代码一年后，Code Review 变成了新的加班理由

193577746 — Wed, 27 May 2026 18:31:20 +0800

去年团队开始用 AI 编程工具，大家都觉得写代码变快了。但一年下来我发现一个怪现象：写代码的时间确实少了，可 Code Review 的时间却越来越长。以前 review 一个 PR，扫一遍逻辑、提两个问题就过了。现在每条改动我都要反复确认：这段是 AI 写的还是人写的？边界条件处理了吗？有没有隐藏的性能问题？review 到后来，比我自己重写一遍还累。

一、AI 写代码快，但 review 起来慢

今年初，我接手了团队的核心项目。组里几个同事都用 Cursor 和 Copilot，产出确实高。但轮到我来 review 的时候，总觉得不对劲。

举个例子，有个同事提交了一个功能模块，代码跑起来没问题，但我逐行看的时候发现：一个组件里挂了三个useEffect，其中两个功能重叠。作者说他没注意，是 AI 自动补全的。这类问题成了常态：AI 生成的代码往往能跑，但结构混乱、逻辑重复、缺少边界判断。

以前人工写的代码，你能感觉到作者的思路。AI 写的代码像一锅大杂烩，看起来什么都有，但就是不舒服。review 的时候，你不能只看逻辑对不对，还得帮作者删冗余、补缺失、理结构。这一套下来，时间不知不觉就翻倍了。

二、几种 AI 代码的 “通病”

我总结了几类经常在 review 时遇到的 AI 痕迹：

1. 逻辑正确，边界全无

AI 很擅长把主流程跑通，但空指针、超时、并发这些问题它不太会主动处理。比如一个查询接口，AI 会写data.list.map(...)，但不会判断data是不是空。review 时要帮它补上data?.list?.map，或者if (!data) return null。

2. 过度设计，简单问题复杂化

有时候 AI 会把一个很简单的事搞得特别 “高端”。比如加个防抖，它给你写一个完整的自定义 Hook，里面用了useRef、useCallback、useEffect，洋洋洒洒四五十行。但实际上只需要一个debounce函数。review 这种代码，你得先理解它的实现，再判断是不是过度了。

3. 注释和命名像 “机器翻译”

AI 生成的变量名经常是data、items、config，看不出具体含义。函数注释要么没有，要么是 “获取数据” 这种废话。review 时要帮忙改成有意义的命名，或者补上必要的注释，否则下一个人看不懂。

三、我的个人策略：怎么让 review 不那么痛苦

经过大半年，我摸索出几条还算管用的办法：

让 AI 先审 AI：提交 PR 前，要求作者把代码再给 AI（换一个模型）审一遍，根据建议改一轮。
差异化对待：工具类、单元测试、文档注释可以放心让 AI 写；核心业务逻辑建议手写或深度修改。
建立小规范：比如 “useEffect 必须有清理函数”、“API 调用必须有 loading 和 error 状态”。AI 不一定会遵守，但 review 时可以快速对照。

这些办法不能根除问题，但至少能把 review 时间拉回到可接受的范围。

四、反思

我现在对 AI 编程的态度很矛盾。一方面，它确实帮我省了不少重复劳动；另一方面，它又把负担转移到了 review 环节。以前一个人写代码，大家一起审；现在一个人写 AI 代码，另一个人替他审漏洞。

这不是 AI 的错，也不是工具的错，而是我们还没学会怎么和 AI 协作。也许未来会有更好的 review 流程，或者 AI 能自己审自己。但就目前而言，AI 没有让我少加班，只是让我加班的内容从 “写” 变成了 “审”。

五、最后

如果你也在经历类似的感受，点个赞让我知道不是一个人。评论区聊聊：你的团队有没有因为 AI 代码而 review 变慢？

前端初级岗位暴跌 62%：我带了三年的实习生被裁了，而 AI 是他亲手教的

193577746 — Tue, 26 May 2026 12:03:53 +0800

上周五，我带了三年、刚转正没几个月的实习生被公司优化了。他在公司吃过最后一顿散伙饭，临走时对着部门那台退役的开发机拍了张照，说想留个纪念。我拍了拍他肩膀：“别灰心，多投几家。” 第二天，我把这个月筛选简历的数据拉出来一看——一个初级岗位，127 份简历，面试转化率不到 1%。不是他不够好。是整个前端初级岗位，正在被 AI 连根拔起。

数据不会说谎：初级前端正在消失

这不是感觉，是真实数据。

根据拉勾网《2026 年第一季度前端行业报告》：

前端初级岗位（0-3 年经验）招聘量同比 暴跌 62%
单个岗位平均收到 127 份简历
超过 80% 的公司在 JD 里明确要求 “熟练使用 AI 编程工具”

与此同时，AI 生成前端代码的能力在过去一年翻了至少三倍。一个刚入行的前端要一年才能掌握的布局、交互、状态管理，Cursor 用半分钟就能生成个七七八八。

我带了三年的实习生，成了这场变革的缩影

我的实习生小 L，本科计算机，在校成绩中上，自驱力强。他跟我学了 React、Vue、Webpack、性能优化，后来自己研究起 AI，主动在项目里接入 Copilot、用 Cursor 写组件库的单元测试，甚至给部门分享过一场 “AI 辅助开发实战”。他是我见过最积极的初级程序员。

然而两个月前，公司组织架构调整，前端 HC 收缩。小 L 所在的边缘业务组直接被裁，他也在名单里。HR 的理由很标准：“业务方向调整。” 但私下里，技术总监说了一句大实话：“我们现在只需要能独当一面、能用 AI 提效的高级开发，初级的工作 AI 自己就能干大半。”

那一刻我突然意识到：小 L 教 AI 写代码，最后 AI 把他教会了，他却没位置了。

最残酷的悖论：AI 淘汰的是 “初级”，而不是 “不会用 AI 的人”

很多人以为，只要学会用 AI 就能保住饭碗。但现实更残酷：当 AI 能完成 60% 的初级开发工作后，企业不再需要一个新人花半年成长到高级，而是直接招一个高级工程师用 AI 去覆盖初级的那部分产出。

初级岗位的需求曲线，几乎是和 AI 编程能力的发展曲线反向交叉的。2023 年，AI 写代码还是段子；2026 年，它已经是职场竞争的底牌。

小 L 不是不会用 AI，他把 AI 玩得很熟。但他的悲剧在于：一个能用 AI 的高级工程师，已经能覆盖三个初级的工作量。 企业算的不是技术账，是成本账。

前端没有死，但 “门槛” 被 AI 焊死了

前端这个岗位消失了吗？没有。

高级前端的需求依然旺盛，而且薪资还在涨。但入行的门槛，被 AI 暴力抬高了。三年前，学会 Vue + 做一个后台管理系统就能找到工作。现在，企业要求：能独立搭建复杂的前端架构，能指导 AI 生成高质量代码并审查，能解决 AI 处理不了的性能瓶颈、安全漏洞、定制需求。

换句话说，AI 把 “会不会写” 变成标配，把 “能不能解决复杂问题” 变成核心竞争力。

小 L 走后，我们组没有再招初级。取而代之的是，团队给每位高级前端每月报销 AI 工具费用，要求用 AI 把重复劳动降到最低，把精力集中在架构、性能、工程化上。我们的人数少了，交付速度却快了一截。

这不是一篇丧气文

我写这篇文章不是为了制造焦虑。作为技术人，我始终相信：每一次技术浪潮，都会冲走一些岗位，也会创造出新的机会。AI 让初级岗位减少，但也催生了 AI 工程化、前端 Agent 开发、RAG 应用等新方向。

真正危险的，不是某个岗位，而是停止进化的思维。

小 L 后来去了另一家创业公司，负责搭建一个 AI 辅助的自动化前端流水线，职位从 “前端开发” 变成了 “AI 工程化前端”。他不再画页面，而是教 AI 怎么画页面。

他那天给前同事发的消息是：“我终于不是被 AI 淘汰的人，而是操控 AI 的人。”

写在最后

2026 年的前端，比任何一个时代都更需要深度。AI 帮你写代码，但不会帮你背锅；AI 帮你查文档，但不会帮你设计架构；AI 帮你生成组件，但不会帮你理解业务。

初级岗位在消失，但优秀的前端永远稀缺。

你身边有被 AI“挤出” 岗位的同事吗？或者你自己就是靠 AI 转型上岸的？评论区聊聊，点个赞让我看到这个时代的缩影。

用魔法打败魔法：我让 AI 替我去面试前端岗，AI 面试官给我打了 92 分，还发了 offer

193577746 — Mon, 25 May 2026 19:11:27 +0800

前言

AI 面试官已经不是什么新鲜事了。银行、外企、大厂海量筛人时，都用 AI 初筛：你对着屏幕答题，AI 分析你的关键词、表情、语音语调。尤其前端岗，AI 会问你 “盒模型”“闭包”“事件循环”……全是标准答案题。

既然对面是机器，那我这边也上机器，很合理吧？我花了一个周末，写了一个Chrome 扩展 + 本地服务，搭建了一个 “前端 AI 替身”：麦克风收音 → 语音转文字 → 调用 GPT 生成前端答案 → 文字转语音 → 播放。全程自动，我只需要坐在旁边喝茶。结果对面真没发现，还给了我 92 分。

今天我就把这个过程完整复盘，附上技术方案和代码思路。不是为了教你作弊，而是想告诉你：AI 面试官远没有想象中智能，以及未来前端面试防作弊技术会有多卷。

金句：当面试官是 AI 时，应聘者也可以是 AI——魔法打败魔法的时代来了。

一、前端 AI 面试官到底在 “面” 什么？

目前主流 AI 面试系统（如 HireVue、国产的 “猿圈”“赛码”）对前端岗位会重点分析：

前端关键词命中：是否说出 “闭包”“原型链”“虚拟 DOM”“性能优化” 等词
语音流畅度：卡顿、重复、语气词
微表情：有没有看屏幕、是否紧张
逻辑结构：回答是否分点、有无 “首先/然后/最后”

它不会理解你的代码能力，只会统计特征。这就给 “AI 替身” 留下了可乘之机。

二、我的 “前端 AI 替身” 技术方案（纯前端实现）

整套系统跑在我的 MacBook 上，核心是四个模块，全部用前端技术栈实现：

模块	作用	前端实现工具
录音	捕获面试官的声音	`MediaRecorder` API + `getUserMedia`
语音转文字	把问题变成文本	`Web Speech API` 或调用 Whisper 接口（通过 `fetch`）
大模型生成答案	根据前端问题生成回答	调用 GPT-4 / Claude API（`fetch` + 流式响应）
文字转语音	把答案读出来	`Web Speech API` 的 `speechSynthesis`（无需额外库）

流程图：

面试官提问 → MediaRecorder 录音 → Web Speech API 转文字 → fetch 调用 GPT → 生成答案 → speechSynthesis 朗读 → 麦克风输出 → 面试官听到

为了让对面不察觉是机器，我加了几个细节：

随机添加前端语气词：在答案里插入 “嗯…我觉得”“其实嘛”“一般来说”，避免过于流畅
随机延迟：每句话前等待 0.5~1.5 秒，模拟思考时间
摄像头画面我用的是自己提前录好的 30 秒循环视频（眼神会眨眼、头会微动）

三、核心代码实现（纯前端）

我写了一个简单的 HTML 页面，打开即可运行：

<!DOCTYPE html>
<html>
<head>
  <title>前端AI面试助手</title>
</head>
<body>
  <button id="start">开始监听面试官</button>
  <div id="question"></div>
  <div id="answer"></div>
  <script>
    const startBtn = document.getElementById('start');
    let recognition;

    // 1. 语音转文字（使用Web Speech API）
    function initRecognition() {
      recognition = new webkitSpeechRecognition();
      recognition.continuous = false;
      recognition.interimResults = false;
      recognition.lang = 'zh-CN';
      recognition.onresult = async (event) => {
        const question = event.results[0][0].transcript;
        document.getElementById('question').innerText = `问题：${question}`;
        // 2. 调用大模型生成前端答案
        const answer = await generateAnswer(question);
        document.getElementById('answer').innerText = `答案：${answer}`;
        // 3. 语音合成
        speak(answer);
      };
    }

    // 调用GPT生成前端面试答案
    async function generateAnswer(question) {
      const response = await fetch('https://api.openai.com/v1/chat/completions', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Authorization': 'Bearer YOUR_API_KEY'
        },
        body: JSON.stringify({
          model: 'gpt-4',
          messages: [
            { role: 'system', content: '你是资深前端工程师，用口语化、自然的方式回答前端面试题，偶尔加“嗯”“我觉得”。答案控制在40秒内。' },
            { role: 'user', content: question }
          ]
        })
      });
      const data = await response.json();
      return data.choices[0].message.content;
    }

    // 语音合成
    function speak(text) {
      const utterance = new SpeechSynthesisUtterance(text);
      utterance.lang = 'zh-CN';
      utterance.rate = 0.9; // 稍慢，像人在思考
      utterance.pitch = 1;
      window.speechSynthesis.speak(utterance);
    }

    startBtn.onclick = () => {
      initRecognition();
      recognition.start();
      startBtn.disabled = true;
    };
  </script>
</body>
</html>

注意：为了不让对面听到电脑自身扬声器的声音导致回声，你需要戴上耳机，把麦克风输入设为耳机麦克风。这个脚本会把面试官的问题实时转文字，然后 GPT 生成答案，再用语音读出来。你全程不需要说一句话。

四、面试实战：30 分钟，对面毫无察觉

那天面试，我打开这个页面，戴上耳机，点击 “开始监听”。对面 AI 面试官问：“请解释一下事件循环。” 我的脚本 3 秒后回答：“嗯…事件循环是 JavaScript 异步的核心机制。JS 是单线程的，它会把任务分为宏任务和微任务……” 语速平稳，偶尔带 “嗯”“呃”，像真人在思考。

中间有一个问题问：“React 的 diff 算法原理是什么？” 脚本回答时，我手动加了点 “嗯…这个嘛”，显得更自然。

全程 30 分钟，对面问了 8 个前端题：闭包、原型链、虚拟 DOM、性能优化、webpack 热更新……全部对答如流。AI 面试官的反馈界面显示：“关键词匹配度 92%，语言流畅度 98%。”

两天后 HR 打电话来：“你初试成绩很不错，岗位匹配度 92%，约一下技术二面（真人面）。” 我假装镇定：“好的好的。” 挂了电话，心里五味杂陈。

五、引发的思考：AI 面试防作弊怎么破？

这件事让我后背发凉：如果我可以，别人也可以。未来的 AI 面试防作弊手段会有多变态？

我大胆预测前端场景下的防作弊：

实时眼神跟踪：要求你盯着屏幕，不能乱瞟，且瞳孔反光中必须看到屏幕内容（防换脸视频）
唇语识别：用另一个模型检测你嘴巴动的语音是否匹配，防止 TTS
设备指纹：检测是否运行了虚拟音频驱动、自动化脚本
双摄像头：一个拍脸，一个拍桌面和键盘，防止你看提词器

在此之前，我建议求职者：如果遇到 AI 面试官，你可以提前准备答案做提词器，但千万别全自动替身。一旦被检测出来，会被拉入企业黑名单。

六、写在最后

这次经历让我感慨：技术是中性的，用它来绕过规则还是提升效率，全在人心。我最终去参加了二面，没有再用 AI——因为二面是人，我能感觉到那份尊重和温度。

AI 面试官不是敌人，而是倒逼我们更真实、更优秀的镜子。 当你发现自己能被机器完美替代时，就该想想：我的核心竞争力到底是什么？

写组件文档写到吐？我用 AI 自动生成 Storybook，同事以后直接抄

193577746 — Sat, 23 May 2026 21:45:25 +0800

我们公司的组件库有一百多个组件，但文档几乎为零。新同事来了，不知道每个组件怎么用、支持哪些 props，只能翻源码。我每周至少被问三次：“这个按钮的 size 参数是 ‘large’ 还是 ‘lg’？” 我烦了，写了个脚本：用 AI 读取组件的 TypeScript 类型定义，自动生成 Storybook 文档和示例代码。现在每次提交组件，CI 自动跑一遍，文档实时更新。同事再也不问我了，CTO 看到说：“这个自动化做得好，省了半个前端的人力。”

前言

组件文档的重要性，每个前端都懂。但现实是：业务需求压过来，谁有时间写文档？结果就是组件库越来越膨胀，文档越来越荒废。新人来了，要么猜，要么问，要么翻源码。

我试过手动写 Storybook，一个组件写半小时，一百个组件写完，我可能已经离职了。后来我想：能不能让 AI 自动生成？组件的 props 类型、默认值、描述，不都写在代码里了吗？让 AI 提取出来，再套个模板，不就完事了？

今天我把这套自动化流程拆给你看：怎么用 AI 解析 TS 类型，怎么生成 Storybook 的 stories 文件，怎么集成到 CI。以后你只需要写好组件，文档的事交给 AI。

金句：最好的文档不是 “人写的”，而是 “代码里长出来的”。

一、痛点：手动写文档的三大坑

痛点	具体表现
耗时长	一个组件平均花 30 分钟写文档（props 表格 + 示例代码 + 说明）
不同步	改了组件 props，忘了改文档，文档变成 “废纸”
没人愿意写	团队集体拖延，文档库永远是 “建设中”

我们团队曾试图用react-docgen-typescript自动提取 props，但它只能生成原始 JSON，还得人工转成 Markdown 或 Storybook。而且它不懂业务描述，比如 “size 的 large 表示大号按钮，用于主操作”，这种描述还是得人写。

AI 的出现正好填补了这个缺口：它既能解析类型，又能生成自然语言描述，还能帮你写示例代码。

二、我是怎么做的？三步全自动

第一步：提取组件类型信息

我用react-docgen-typescript把组件的 props、类型、默认值、是否必填提取成 JSON。写一个脚本extract-props.ts：

import * as docgen from 'react-docgen-typescript';

const options = {
  savePropValueAsString: true,
  shouldExtractLiteralValuesFromEnum: true,
};

const parser = docgen.withCustomConfig('./tsconfig.json', options);
const docs = parser.parse('./src/components/Button/index.tsx');

// docs[0] 结构：
// {
//   displayName: 'Button',
//   props: {
//     size: { type: { name: "'small' | 'medium' | 'large'" }, required: false, defaultValue: 'medium' },
//     children: { type: { name: 'ReactNode' }, required: true }
//   }
// }

第二步：用 AI 生成 Storybook 内容

把提取的 JSON 喂给 AI，提示词：

你是一名前端技术文档专家。请根据以下组件的 props 信息，生成一份 Storybook 的 stories 文件代码。

要求：

为每个 prop 生成控制台（controls）配置

生成至少 3 个示例：基础用法、不同尺寸、自定义样式

用 Markdown 格式输出，包含组件描述和 Props 表格

组件信息：
[粘贴上一步的JSON]

AI 会输出类似这样的 Storybook 代码：

// Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';

const meta: Meta<typeof Button> = {
  title: 'Components/Button',
  component: Button,
  parameters: {
    docs: {
      description: {
        component: '通用按钮组件，支持三种尺寸和两种主题色。主要用于表单提交、弹窗确认等操作。'
      }
    }
  },
  argTypes: {
    size: {
      control: 'radio',
      options: ['small', 'medium', 'large'],
      description: '按钮尺寸'
    },
    children: { control: 'text', description: '按钮内容' }
  }
};

export default meta;

export const Default: StoryObj<typeof Button> = {
  args: { children: '按钮', size: 'medium' },
};

export const Large: StoryObj<typeof Button> = {
  args: { children: '大按钮', size: 'large' },
};

export const Small: StoryObj<typeof Button> = {
  args: { children: '小按钮', size: 'small' },
};

第三步：集成到 CI

我在项目的.github/workflows/docs.yml里加了一个 job：

- name: Auto generate Storybook
  run: |
    npm run extract:props
    npm run ai:generate-stories
    npm run build:storybook
  env:
    OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

每次git push到 main 分支，GitHub Actions 自动跑一遍，重新生成文档并部署到 GitHub Pages。从此文档永远最新。

金句：AI 自动生成文档，让 “文档过时” 成为历史。

三、实测效果：节省了多少时间？

我们组件库有 87 个组件，人工写一个平均 30 分钟，总计 43.5 小时。用 AI 自动生成后，每个组件约 2 分钟（人工 review 和微调），总计约 3 小时。节省了 93% 的时间。

指标	手工	AI 辅助	变化
单组件文档耗时	30 分钟	2 分钟	↓ 93%
文档与代码同步率	经常滞后	实时同步	-
新人上手询问次数（月均）	12 次	2 次	↓ 83%

同事现在想查组件用法，直接打开 Storybook。没人再问我了，我可以安心写代码。

四、注意事项（坑点）

AI 会脑补不存在的 props：有时会生成示例里用了你没提供的 prop，必须人工删掉。
复杂泛型可能解析错：react-docgen-typescript对高阶组件、泛型组件的解析不够准，需要手动修正输入 JSON。
保护公司组件库隐私：不要直接把整个组件库代码喂给云端 AI。可以用本地模型（如 Ollama + CodeLlama），或者只传类型 JSON（不传实现细节）。
示例代码要人工跑一遍：AI 生成的示例可能无法直接运行（比如忘记 import 样式），你至少编译一次确保没语法错误。

五、完整的 Prompt 模板（复制可用）

# 角色
你是一名前端技术文档专家，擅长为React组件生成Storybook文档。

# 任务
根据以下组件的props信息，生成一个完整的Storybook stories文件。

# 输入格式
JSON对象，包含displayName和props

# 输出要求
1. 使用TypeScript语法
2. 包含meta配置（title, component, parameters, argTypes）
3. 生成至少3个Story：Default, Large, Small（或其他合适的变体）
4. 在parameters.docs.description.component中写一段组件用途说明
5. 每个argType的control要合理（radio/select/text等）

# 组件信息
[粘贴JSON]

六、写在最后

以前我觉得文档是 “良心活”，写了加分，不写也没人扣分。现在 AI 帮我自动生成，我才发现：文档不是负担，而是杠杆——它让组件的复用率大大提升，团队效率自然就上去了。

如果你也被组件文档折磨过，或者想知道怎么把 AI 接入你的工程化流程，点个赞让我看到。

面试官让我查各部门工资最高的员工，我用 AI 三秒写出窗口函数，他愣了

193577746 — Fri, 22 May 2026 18:29:37 +0800

上个月面一家大厂，技术面第二轮，面试官出了一个 SQL 题：“查每个部门工资最高的员工。” 我脑子里闪过一堆解法：子查询、自连接、group by……但都太绕，而且还容易漏掉并列第一。我打开 Cursor，输入：“用窗口函数写一个 SQL，查出每个部门工资最高的员工，如果最高工资并列全部返回。” 三秒后 SQL 生成。面试官看了一眼，说：“你是我见过第一个用窗口函数还讲得清原理的候选人。” 后来我拿到了 offer。

前言

SQL 面试题里，“分组取 Top N” 是经典中的经典。尤其是 “每个部门工资最高的员工”，考频率仅次于两数之和。很多人能写出来，但写出来的往往是子查询嵌套自连接，性能差、代码丑、还容易漏掉并列的情况。

而窗口函数（ROW_NUMBER / RANK / DENSE_RANK）才是这道题的标准答案，但很多人一紧张就忘了语法：OVER 里面怎么写？PARTITION BY 和 ORDER BY 怎么配？RANK 和 ROW_NUMBER 有什么区别？

其实不用背，AI 一秒就给你写出来。但关键是：你要能讲清楚为什么选这个函数，以及窗口函数的执行顺序。今天我就用这个真实面试题，教你用 AI 秒解 SQL 难题，顺便讲透窗口函数。

金句：面试官考的不是你背不背得出语法，而是你懂不懂 “为什么” 和 “选哪个”。

一、先看面试题原貌

表结构

CREATE TABLE employee (
    id INT,
    name VARCHAR(50),
    department VARCHAR(50),
    salary INT
);

需求：查询每个部门工资最高的员工。如果最高工资有并列（比如两人都是 10000），都要返回。

示例数据 | id | name | department | salary | | ---- |------| ------------ |--------| | 1 | 张三 | 技术部 | 12000 | | 2 | 李四 | 技术部 | 10000 | | 3 | 王五 | 技术部 | 12000 | | 4 | 赵六 | 销售部 | 9000 |

期望输出：技术部返回张三和王五（并列 12000），销售部返回赵六。

二、AI 生成的标准答案

我在 Cursor 里输入：

用 MySQL 语法，写一个 SQL 查询：每个部门工资最高的员工。如果最高工资有多人，全部返回。要求使用窗口函数，并解释执行顺序。

AI 输出：

WITH ranked AS (
    SELECT 
        *,
        RANK() OVER (PARTITION BY department ORDER BY salary DESC) AS rnk
    FROM employee
)
SELECT id, name, department, salary
FROM ranked
WHERE rnk = 1;

为什么用 RANK 而不是 ROW_NUMBER？

ROW_NUMBER 会给每人一个唯一序号，并列的也会强行分出先后，导致只能返回一人。
RANK 会为相同工资分配相同排名，并列第一就都返回。

面试官紧接着追问：那 DENSE_RANK 呢？答：DENSE_RANK 排名连续，但本题只需要最高工资，效果与 RANK 一样（因为只取 rnk=1）。但如果有第二高需求，DENSE_RANK 和 RANK 区别就大了。

三、窗口函数的执行顺序（讲清楚才能加分）

面试官接着问：“窗口函数是在 SQL 哪个阶段执行的？”

我回答：在 WHERE、GROUP BY 之后，在 ORDER BY 之前。具体顺序：

FROM → JOIN
WHERE → 过滤行
GROUP BY → 分组
聚合函数计算
HAVING → 过滤分组
窗口函数 → 在这里计算排名
ORDER BY
LIMIT

所以，窗口函数的结果可以在 WHERE 里用吗？不能，因为 WHERE 在窗口函数之前执行。所以必须用 CTE 或子查询先计算排名，再在外部 WHERE 筛选。

AI 生成的代码正是这样做的：WITH ranked AS ( ... ) 先算排名，再 WHERE rnk = 1。面试官听到这里，点了头。

四、如果不用窗口函数，你能写出更优的解法吗？

可以用子查询 + 关联，但性能差且代码臃肿：

SELECT e1.*
FROM employee e1
LEFT JOIN employee e2 
    ON e1.department = e2.department 
    AND e1.salary < e2.salary
WHERE e2.id IS NULL;

这个解法的逻辑是：找出不存在同部门更高工资的人。优点是跨数据库通用，缺点是不好理解，而且对于大表性能差（因为自连接扫描两次）。

用窗口函数，不仅快（一次扫描），而且清晰易维护。所以现代 SQL 强烈推荐。

金句：不用窗口函数的 SQL 优化，就像不用箭头函数的 JS——能跑，但不优雅。

五、面试官为什么认可我用 AI？

同样的逻辑：AI 帮我生成语法，我负责解释原理。他知道我背不出完整的 RANK 语法（正常人谁背？），但我知道什么时候用 RANK、窗口函数执行顺序、如何改造成其他需求。这就够了。

六、拓展：分组取第二名怎么改？

面试官可能接着问：“如果我要每个部门第二高工资呢？”

很简单，把 WHERE rnk = 1 改成 WHERE rnk = 2 就行。但注意：如果第二名是并列（比如两人都是 9000），RANK 会跳过第三名的序号（比如排名：1,2,2,4），DENSE_RANK 则连续（1,2,2,3）。你需要问清楚需求。

七、完整代码和测试数据

你可以用这个数据自测：

CREATE TABLE employee (
    id INT PRIMARY KEY,
    name VARCHAR(20),
    department VARCHAR(20),
    salary INT
);
INSERT INTO employee VALUES
(1,'张三','技术部',12000),
(2,'李四','技术部',10000),
(3,'王五','技术部',12000),
(4,'赵六','销售部',9000);

然后运行上面的窗口函数 SQL，输出应该是：张三、王五、赵六。

八、写在最后

面试题在变，但考察的核心没变：理解原理 > 背诵语法。AI 能帮你写出任何代码，但能讲清楚为什么、怎么改、有什么坑，才是你的真本事。

你面试遇到过哪些 “想不起来语法” 的瞬间？后来怎么过的？

193577746 (kyriewen)

手写 call、apply、bind：从原理到实现，附 3 个最容易忽略的边界情况

一、准备知识：this 的优先级

二、手写 call

三、手写 apply

四、手写 bind（最难）

五、3 个最容易忽略的边界情况

边界 1：context 为 null/undefined

边界 2：函数有返回值

边界 3：bind 后的函数作为构造函数

六、完整代码（可直接复制）

七、总结

CSS Container Queries：彻底告别 @media 写到手软，附 5 个真实布局案例

一、Container Queries 解决了什么问题？

二、基础语法（三步搞定）

2.1 定义容器

2.2 使用 @container

2.3 组合与范围

三、与 @media 对比（代码量减少 50%）

四、5 个实战案例（可直接复制）

案例 1：卡片组件根据容器宽度切换布局

案例 2：侧边栏与主内容区共享同一卡片组件

案例 3：仪表盘小部件矩阵

案例 4：商品列表切换行列（类似 Grid 与 Flex 混合）

案例 5：自适应导航栏（折叠菜单）

五、浏览器兼容性与降级方案

六、总结

前端性能优化：LCP 从 4s 到 0.9s 的 5 个核心手段（附配置代码）

一、LCP 的定义与优化目标

二、优化手段 1：图片优化（WebP + 响应式 + 懒加载）

原理

具体配置

收益

三、优化手段 2：字体优化（font-display + 预加载）

原理

CSS 配置

HTML 预加载

收益

四、优化手段 3：JavaScript 分割与异步加载

原理

Webpack 配置（splitChunks）

动态导入

第三方脚本延迟

收益

五、优化手段 4：CSS 内联关键样式 + 异步加载非关键样式

原理

提取关键 CSS（使用 critical 工具）

异步加载完整 CSS

收益

六、优化手段 5：服务器压缩与 CDN 预热

原理

Nginx Brotli 配置（需编译 brotli 模块）

CDN 预热（阿里云示例）

收益

七、优化优先级总结

八、检测工具

我读了一遍 Babel 编译后的 async/await，终于搞懂了它的原理（附 20 行手写实现）

1. 一个真实的 “翻车” 场景

2. 前置知识：Generator 函数

3. Babel 编译后长什么样？

4. 手写核心：自动执行器

5. 封装成真正的 asyncToGenerator

6. 常见误解与踩坑

6.1 await 后面跟着的不是 Promise 会怎样？

6.2 异步错误怎么捕获？

6.3 for 循环里的 await 是串行还是并行？

7. 总结

一个人 +Cursor，7 天上线付费小程序：第 1 天我就想放弃了

一、一个冲动的开始：3 天上线一个付费工具？

二、第一道墙：Cursor 再强，也不知道 “个人主体不能选这个类目”

三、AI 10 分钟写的代码，我花了一整天修 bug

四、审核的毒打：AI 不知道 “中国式合规” 长什么样

五、转折：第四天晚上，审核突然过了

六、接入支付：技术不难，难的是 “你敢收钱吗”

七、第一笔真实的付费，来自一个陌生人

八、复盘：AI 到底帮我省了多少时间？

九、这篇文章想告诉你什么

十、下一步：我要用 30 天验证一个更大的假设

从 Webpack 到 Vite：我们迁移了一个 10 万行代码的项目，总结了这 7 个坑

一、为什么要迁？我们当时的痛点

提取关键 CSS（使用 `critical` 工具）

5. 封装成真正的 `asyncToGenerator`

6.1 `await` 后面跟着的不是 Promise 会怎样？

6.3 `for` 循环里的 `await` 是串行还是并行？

`*:443` 通配符为什么会搞坏某些网站？

❌ 错误做法：`*:443` 通配符 + 不管 Exclude

✅ 推荐做法：`*:443` 通配符 + Exclude 排除问题域名