
前端页面最终很大一部分价值，都来自交互。

而交互里最典型的一类，就是表单输入。

登录、注册、搜索、提交反馈、填写资料，这些几乎都离不开表单能力。所以虽然表单是基础内容，但它非常重要。

## 表单的核心作用

表单的本质是收集用户输入。

这看起来简单，但一旦进入真实业务，就会涉及：

- 文本输入
- 单选、多选
- 下拉选择
- 校验
- 提交

所以表单其实是用户和系统之间非常关键的一个桥梁。

## 常见表单元素

最常用的通常包括：

- `input`
- `textarea`
- `select`
- `button`

其中 `input` 又有多种类型，例如：

- `text`
- `password`
- `checkbox`
- `radio`

不同类型对应不同输入场景。

## label 很重要

很多人刚开始写表单时，会把重点只放在输入框上，但 `label` 同样重要。

它不仅让用户更容易理解字段含义，也让表单结构更完整。

## 表单提交不只是按钮点击

表单天然支持提交行为，这也是它和普通容器元素的重要区别之一。

理解这一点之后，你会更容易明白：

- 为什么按回车会触发表单提交
- 为什么有时要阻止默认提交行为

## 前端校验和表单体验

真实开发里，表单体验很大程度取决于：

- 提示是否清楚
- 错误信息是否及时
- 输入控件是否易用

所以表单不只是“能填进去”，而是要让用户明白自己该怎么填、哪里填错了。

## 写在最后

HTML 表单是前端交互能力里非常基础的一部分。它看起来简单，但几乎贯穿了所有和用户输入有关的功能。

只要把表单元素、标签、提交行为这些基础认知打稳，后面再学更复杂的表单逻辑时会轻松很多。


HTML 表单基础回顾：前端交互实际开发中就是从这里开始的


Vue 3 发布之后，大家讨论最多的点之一就是响应式实现变了。

对很多日常业务开发来说，最先感受到的并不是底层细节，而是一些以前容易别扭的地方开始顺了。

## 为什么大家会关心这一层

因为响应式不是 Vue 的一个外围能力，它几乎决定了你日常写组件时的基本体验。

数据怎么跟界面联动、对象新增字段时会不会更新、数组变化是否自然，这些都属于响应式系统的范围。

## 写在最后

Vue 3 响应式改动之所以值得关注，不是因为底层名词更新了，而是因为它会直接改变你写业务代码时的感觉。

很多框架变化看起来离业务很远，响应式这件事不是。它几乎就是日常开发体验本身。


Vue 3 响应式变化初看：Proxy 带来的不只是写法变化


Vite 很快，这一点几乎不用太多证明。问题是，项目迁移从来都不只是“新工具更快，所以换过去”。

真正值得先想清楚的是：你现在的 Vue 项目依赖了多少旧工具链假设。

## 迁移前最该先看什么

通常至少要先盘一盘这几类东西：

- 自定义 Webpack 配置有多少
- 别名、环境变量、插件是否深度绑定
- 第三方 loader 是否很多
- 构建脚本和部署流程有没有耦合

如果这些东西很重，迁移就不只是换个启动命令。

## 快是收益，但不是全部收益

Vite 最明显的优势确实是开发快。

但迁移值不值得，最终还是看两件事：

- 迁移成本高不高
- 长期收益能不能覆盖这次改动

## 写在最后

Vue 项目迁到 Vite，最怕的不是踩坑，而是预期太轻。

如果把它看成一次工具升级，准备往往不够；如果把它看成工程假设切换，很多判断就会更稳。


把 Vue 项目迁到 Vite 之前，先想清楚你迁的是速度，还是整套工程假设


数组是 JavaScript 里使用频率非常高的数据结构。

无论是列表渲染、接口数据处理、条件筛选，还是状态更新，很多逻辑最后都会落到数组操作上。

所以理解常用数组方法的区别，比死记语法更重要。

## map：把一个数组变成另一个数组

`map` 最适合做转换。

```javascript
const numbers = [1, 2, 3];
const result = numbers.map(item => item * 2);
```

它不会修改原数组，而是返回一个新数组。

这也是它在前端渲染里特别常见的原因，例如把数据列表映射成组件列表。

## filter：筛选出符合条件的项

`filter` 用来保留符合条件的元素。

```javascript
const users = [
  { name: 'Tom', active: true },
  { name: 'Jerry', active: false }
];

const activeUsers = users.filter(user => user.active);
```

它同样会返回一个新数组。

## find：找到第一个符合条件的元素

如果你只需要一个结果，而不是一个数组，`find` 更合适。

```javascript
const user = users.find(item => item.name === 'Tom');
```

它找到后就会返回对应项，没有找到则返回 `undefined`。

## forEach：只做遍历，不返回结果

`forEach` 更适合执行某些副作用操作。

例如：

```javascript
list.forEach(item => {
  console.log(item);
});
```

如果你的目标是生成新数组，那通常不该用 `forEach`。

## some 和 every

这两个方法也很实用：

- `some`：只要有一个满足条件就返回 `true`
- `every`：必须全部满足才返回 `true`

它们特别适合做条件判断。

## 写在最后

数组方法的关键不在于记住名字，而在于先想清楚你的意图：

- 要转换，就用 `map`
- 要筛选，就用 `filter`
- 要找一个，就用 `find`
- 只遍历执行逻辑，就用 `forEach`

只要意图和方法对上，代码会更清楚，也更不容易写乱。


JavaScript 数组常用方法整理：写业务代码时最常用的是哪几个


前端性能问题最让人头疼的地方，不只是慢，而是不知道到底哪里慢。

页面卡顿的时候，团队里常见的第一反应通常是：

- 是不是框架太重
- 是不是组件太多
- 是不是状态管理有问题

这些方向当然可能有关，但如果一上来就把问题归因给“大框架”或“大项目”，通常并不能真正解决问题。

## 先区分是哪一种慢

性能问题不是只有一种。

常见至少有四类：

- 首屏加载慢
- 页面切换慢
- 滚动卡顿
- 输入、点击反馈慢

这四类问题对应的排查方向可能完全不同。

如果一开始不分类，只说“页面有点卡”，后面优化就很容易到处试错。

## 首屏慢先看资源和请求

如果用户第一次打开页面就慢，优先看：

- JS 包体积
- 图片资源大小
- 接口耗时
- 阻塞渲染的资源

这类问题实际开发中和框架无关，而是资源策略不合理。

例如：

- 首页一次加载太多模块
- 首屏请求串行
- 大图没有做压缩
- 字体加载阻塞首屏文本渲染

## 交互卡顿先看渲染链路

如果是点击按钮、切换筛选、输入文本时卡，优先排查：

- 是否有大量不必要的重渲染
- 是否在主线程做了重计算
- 是否列表过大但没做虚拟化
- 是否有动画或布局抖动

这类问题比起网络，更常发生在渲染阶段。

## 不要把“重渲染”当成唯一答案

很多性能文章喜欢把问题都归结为重渲染，但现实中不一定。

页面卡可能来自：

- JS 计算太重
- DOM 数量太多
- 样式重排频繁
- 动画掉帧
- 第三方脚本抢主线程

所以排查时不能只盯着组件 render 次数。

## 列表问题特别容易放大性能缺陷

列表是最常见的性能放大器。

一个页面在数据量少时运行正常，数据量一大就明显变卡，这通常说明：

- 每项渲染成本高
- 状态更新影响整表
- 没做分页或虚拟滚动
- 键值不稳定导致节点频繁重建

列表优化的关键不是“让每一项更聪明”，而是减少不必要的整体更新。

## 排查时尽量用证据，不要靠感觉

性能问题最忌讳“我觉得是这里慢”。

更有效的方式是：

- 看 Performance 面板
- 看 Network 请求瀑布
- 看哪些任务阻塞了主线程
- 看长任务出现在哪里

实际开发中，真正耗时的地方和直觉并不一致。

## 第三方代码也要纳入排查

真实项目里，性能问题不全是自己代码导致的。

例如：

- 埋点 SDK
- 在线客服
- 可视化监控
- 广告脚本
- 富文本编辑器

这些东西一旦在不合适的时机执行，也会明显拖慢页面。

所以排查性能时，不要只看业务代码。

## 一个实用顺序

页面卡顿时，比较实用的排查顺序通常是：

1. 先明确是哪一种慢
2. 再看网络还是渲染主导
3. 找出最重的资源、请求或任务
4. 再决定是拆包、减渲染、改结构，还是延后加载

这个顺序的好处是，能避免一开始就陷入“我是不是该重构整个前端架构”的过度反应。

## 写在最后

前端性能排查最重要的不是技巧，而是顺序感。

只要你先把问题分类，再用工具找证据，很多看起来复杂的性能问题都会逐渐变清楚。页面卡顿并不等于框架有罪，更常见的情况是资源、渲染和交互链路里某个环节在被放大。


前端性能排查思路：页面卡顿时，不要一上来就怀疑框架


这半年里我连续碰到过两个 AI 自动化项目，表面上看都很适合做 Agent，最后做出来的路子却完全不同。也是在这两个项目里，我才真正把“Agent 和工作流的边界”想明白。

第一个项目是内部知识处理流程。输入是文档，输出是摘要、标签、结构化字段，再把结果入库。第二个项目是一个运维助手，目标是接收自然语言指令后去查资料、调用工具、生成处理建议。

最开始团队对这两个项目的直觉差不多：都上 Agent 吧，毕竟多步骤、会调用工具、看起来很智能。

后来回头看，第一个项目如果真按 Agent 做，八成会越做越乱；第二个项目如果只做死工作流，又会显得特别笨。这就是我现在越来越在意的判断点：不是任务里有没有模型，而是路径到底稳不稳。

## 第一个项目教会我的，是“很多流程根本不需要自主规划”

文档处理那个项目刚开始时，也有人提议让模型自动决定每一步怎么做。听上去很先进：先读文档，再判断要不要抽摘要、要不要分类、要不要纠错、最后决定怎么入库。

但我们真正把流程梳理完之后发现，这件事根本没那么开放。

它的真实链路其实很固定：

1. 读文档
2. 提取正文
3. 做字段清洗
4. 生成摘要和标签
5. 输出固定结构
6. 入库

这里面真正需要模型判断的，其实只有个别节点，比如分类和摘要；主流程完全是确定的。

我们后来没有做 Agent，而是把主干写成工作流，再在少数节点上接大模型。结果非常稳。日志清楚，失败能重跑，出了问题也知道卡在哪一步。

这次经历让我第一次明确地感觉到：多步骤不等于 Agent。一个任务就算有六七步，只要路径稳定，它本质上还是流程编排问题。

## 第二个项目让我看到，工作流也会有明显上限

运维助手那次就不一样了。

用户会问：

- “帮我看看这个服务为什么最近报警变多了”
- “对比一下昨天和今天的错误日志趋势”
- “如果我要排查支付回调失败，应该先看哪几个系统”

这种任务的特点是目标清楚，但路径不固定。不同问题，第一步就可能完全不同：

- 有的要先搜知识库
- 有的要先查监控
- 有的要先拉日志
- 有的还得根据前一步结果再决定下一步

我们最早也尝试过工作流化，结果非常别扭。因为你很难提前把所有路径都列出来。流程一旦写死，助手就会表现得像一个菜单系统：能做的事都在预设分支里，一旦用户问法稍微拐一点，就开始答非所问。

这时候 Agent 的价值才真正出来。不是因为它“更高级”，而是它确实更适合这种需要边走边判断的任务。

## 我现在判断 Agent 和工作流，基本看三件事

第一，看路径是不是稳定。

如果一个任务 80% 情况都走同样的步骤，那优先工作流。别为了“智能感”把稳定流程交给模型自由发挥。

第二，看失败成本高不高。

如果一步错了会影响订单、权限、资金、客户数据，那主干流程必须尽量写死。模型可以辅助判断，但不该掌握整个执行权。

第三，看任务是否要求探索未知信息。

如果模型需要先去搜、再比对、再决定下一步，甚至中途可能修正原计划，那才更像 Agent。

这三个问题我现在几乎每次都会问一遍，因为它们能很快帮我把“看起来都像 AI 自动化”的需求拆开。

## 很多团队会误把“多步工具调用”当成 Agent

这是我最近最常看到的一个偏差。

有些系统本质上只是：

1. 读输入
2. 调一个接口
3. 调另一个接口
4. 按模板输出结果

这当然是多步，但不等于 Agent。它没有动态规划，也没有真正的路径选择，只是流程比单步长了一点。

如果把这类流程也包装成 Agent，短期可能显得很先进，长期问题很多。因为一旦让模型自由控制原本可以确定的步骤，你就会开始面对一连串新问题：

- 工具参数为什么变了
- 为啥这次少走了一步
- 为什么昨天成功今天失败
- 失败后该从哪儿恢复

这些问题本来可以靠流程约束直接规避。

## Agent 真正难的地方，从来都不是“会不会想”，而是“出了事怎么兜”

这个认知也是我做第二个项目时被逼出来的。

在 Demo 环境里，Agent 往往看起来很聪明。它会拆任务，会总结，还会自己决定先调哪个工具。可一旦进入真实系统，你马上会碰到完全不同的问题：

- 工具返回半结构化垃圾怎么办
- 上一步失败后，状态存在谁那里
- 一个任务执行到一半中断，能不能恢复
- 模型选错工具时，系统能不能兜底

这些问题不是“提示词再写好一点”就能解决的，它们属于工程治理问题。

所以我现在看一个 Agent 系统，会特别关注这些东西：

- 工具是不是封得干净
- 每一步是否可观测
- 中间状态有没有地方落
- 失败后是否能人工接管

这些事情如果没做好，Agent 再能说，也只是一个容易失控的黑盒。

## 后来我越来越接受一种更务实的做法

很多项目其实不需要在“纯工作流”和“全自主 Agent”之间二选一。

更实用的方式通常是：

- 主干流程写死
- 把模型放在少数确实需要语义判断的位置
- 在开放型环节里再放开自主规划

比如文档项目就是工作流主导，分类和抽取节点交给模型。运维助手则是 Agent 主导，但工具权限、执行范围、输出格式仍然受系统约束。

这种做法没有那么“酷”，但很符合真实交付环境。它既不把模型压成死模板，也不把可控性一把丢掉。

## 写在最后

我现在对 Agent 和工作流的看法已经很简单了：稳定路径别装成智能，自由探索也别硬写成流程。

很多项目不是做不出 AI，而是选错了自动化层级。主干应该被写死的地方，就老老实实写死；真正需要模型判断和规划的地方，再给它空间。边界一旦分清，系统会比“全都交给模型”稳得多，也比“什么都手搓流程”灵活得多。


Vue 3 响应式变化初看：Proxy 带来的不只是写法变化

为什么大家会关心这一层

写在最后

JavaScript 数组常用方法整理：写业务代码时最常用的是哪几个

前端性能排查思路：页面卡顿时，不要一上来就怀疑框架

AI Agent 和工作流的边界：我是在两次自动化项目里把这个问题看清的