很多团队做前端监控的姿势是：

先接一个 SDK，看到了几个报错，然后就没然后了。

最后变成：

• 告警群天天响，大家学会了「静音」；
• 仪表盘很酷，但没人看；
• 真出大问题时，还是靠用户截图。

这篇文章想聊的是：怎么从「有监控」升级到「有闭环」：采集、告警、问题跟踪、复盘一条链路打通。

1. 前端到底要监什么？

可以按三个维度来想：

1. 可用性

   • JS 运行错误（Error、Promise 未捕获）；
   • 资源加载失败（JS/CSS/图片）；
   • 页面白屏/异常重定向。

2. 性能

   • 首屏指标（FCP/FP/TTI 等的近似值）；
   • 接口耗时、失败率；
   • 静态资源加载时间。

3. 行为 & 转化

   • 关键路径的曝光/点击/完成；
   • 异常行为（频繁刷新、某步流失明显）。

实践上，可以先从：错误 + 性能 + 关键链路打点 三件事做起。

2. 采集：埋点 & SDK 一起用

2.1 错误采集

典型方式：

window.addEventListener('error', (event) => {
  reportError({
    type: 'error',
    message: event.message,
    filename: event.filename,
    lineno: event.lineno,
    colno: event.colno,
    stack: event.error?.stack,
  });
});

window.addEventListener('unhandledrejection', (event) => {
  reportError({
    type: 'unhandledrejection',
    reason: String(event.reason),
  });
});

结合 sourcemap 上传，可以把错误还原到源代码行。

2.2 性能采集

利用 Performance API：

有一次线上迭代后，陆续收到反馈：

「系统能用，就是打开慢了一截。」
「首页白屏时间变长了。」

监控一看，某个核心页面的首屏时间从 约 2s 抬升到了接近 5s。
这篇文章就是那次性能优化的实战复盘：我们如何量化问题、定位瓶颈、再一步步把首屏拉回到 1.5s 左右。

1. 先量化，而不是拍脑袋

第一步是搞清楚「慢」在哪：

• 首包下载？
• JS 执行？
• 接口耗时？
• 还是一堆「非必要逻辑」抢在首屏执行？

我们主要用了三种手段：

1. Chrome DevTools Performance 看关键时序；
2. Lighthouse 跑实验室指标；
3. 前端埋点 看真实用户数据（FMP/TTI 的简化近似）。

初步结论：

• JS 资源总体体积较大，首屏要加载的 JS 超过 1MB（压缩后）；
• 首屏渲染完成前存在一段较长的 JS 执行（主线程被占用）；
• 首屏接口本身不是特别慢，但被一些不必要的请求夹在中间。

目标明确：瘦 JS、少阻塞、分优先级。

2. Bundle 拆分：让首屏只拿它真需要的

2.1 分析构建结果

接入 webpack-bundle-analyzer / Vite 插件之后，很快看到几个「大头」：

• 整个 UI 组件库全量引入；
• 某些图表库（在其他页面才用）被打进首屏 bundle；
• 若干工具库重复/未 Tree-shaking。

2.2 做的调整

1. 组件库改为按需引入

   • 把 import ElementUI from 'element-ui' 改成 babel 插件/手动按需；
   • 打包结果里组件库体积明显下降。

2. 路由级别代码拆分

每次提到前端加密，评论区都会有人说：

有 HTTPS 了，还加什么密？
前端代码都是能看到的，没意义。

理论上没错，但在金融/政企等场景里，有些需求不是技术可不可行，而是「要不要多一层安全防护 + 满足合规要求」。

这篇文章从实战出发，聊聊：

• 常见的前端加密需求；
• 对称 / 非对称加密如何组合使用；
• 以及实际落地时的一些坑。

1. HTTPS 已经有了，为啥还要前端加密？

先说前提：HTTPS 必须有，这是基础。
在这个基础上，某些场景仍然会要求：

1. 防止明文敏感信息出现在抓包里

   • 即便是 HTTPS，有些合规要求会明确写「不得以明文形式传输密码等敏感信息」；
   • 抓包截图里看到一串密文，和直接看到手机号/密码，感受是不一样的。

2. 降低中间层日志泄露风险

   • 有时候请求会经过网关、代理、日志系统；
   • 如果这些地方有不规范的日志记录，敏感字段加密可以降低损害。

3. 和现有后端架构/第三方接口对齐

   • 有些历史系统已经约定「密码字段用某种算法加密再传」；
   • 前端需要遵守既有协议。

前端加密不是代替 HTTPS，而是多一层「应用层加密」。

2. 两个基本工具：对称 & 非对称

简单回顾一下：

• 对称加密（如 AES、SM4）：同一把 key 加密解密；
• 非对称加密（如 RSA）：公钥加密，私钥解密（或反之）。

特性：

• 对称加密：速度快，适合加密大量数据，但key 如何安全分发是问题；
• 非对称加密：适合做「密钥交换」，但加密大数据性能较差。

所以常用组合是：

前端生成一个随机对称密钥 → 用后端公钥加密这个密钥 → 发给后端 → 后端用私钥解出密钥 → 后续用这个对称密钥加解密数据。

前端常见实现方式：

• WebCrypto API；
• 或成熟的 JS 加密库（CryptoJS / JSEncrypt / 国密相关库等）。

3. 一个典型的前端加密流程

以「登录密码不可明文传输」为例，设计一个简化流程：

背景

在中后台系统与业务管理类页面中，表单是最常见、也是最容易被低估的一类界面形态。
当字段数量增加、填写规则变复杂时，简单堆砌输入框往往会带来较高的使用成本。

如何在不引入额外学习成本的前提下，提升表单填写效率与可理解性，是前端实现中需要重点考虑的问题。

常见问题分析

1. 必填项不明确

在字段较多的表单中，常见问题包括：

• 必填与非必填混杂展示
• 校验规则只在提交时才触发
• 错误提示信息不清晰

这类问题会显著降低填写效率。

2. 一次性信息输入负担过重

将所有字段集中在一个页面中，容易导致：

• 页面过长，用户难以快速定位
• 心理负担增加，填写中途放弃
• 错误集中暴露，修改成本高

3. 表单状态反馈不足

缺乏清晰反馈时，用户往往无法判断：

• 当前填写是否符合规则
• 是否已满足提交条件
• 提交操作是否成功触发

表单设计与交互实践

1. 明确字段优先级

通过视觉层级区分字段重要性：

• 必填项显式标识
• 非关键字段弱化展示
• 合理使用占位说明与辅助文案

有助于用户快速理解填写重点。

2. 分步骤拆解复杂表单

将长表单拆分为多个步骤：

• 每一步聚焦一类信息
• 提供清晰的进度提示
• 支持上一步回退与数据保留

这种方式能有效降低单次填写压力。

3. 提前进行输入校验

在用户输入过程中进行校验：

• 输入完成后即时提示错误
• 明确指出错误原因
• 避免提交后集中报错

可以显著减少重复操作。

4. 提供清晰的状态反馈

在关键节点给予明确反馈：

• 提交中状态提示
• 成功或失败结果明确展示
• 异常情况提供可操作指引

让用户始终清楚当前所处状态。

工程实现层面的考虑

在实现层面，通常会关注：

• 表单状态集中管理
• 校验逻辑与 UI 解耦
• 表单组件的可复用性

这些实践有助于在多个业务场景中复用同一套表单能力。

总结

复杂表单的设计并不依赖特定行业背景，而是对信息结构、交互节奏与用户认知的综合考量。

通过合理拆分、清晰反馈与一致的交互规则，可以在不增加实现复杂度的前提下，显著提升整体使用体验。

很早之前就对「AI 能不能帮忙看评论、看工单」这件事好奇过，但自己训模型门槛挺高，于是先选了条最省事的路：

找一个云厂商提供的 NLP API，用 HTTP 请求的方式做一层简单封装，做一个「文本分析小工具」。

这篇文章记录的是那次尝试的过程。

注：下面不强调具体厂商名字，主线思路在于「怎么用」，而不是「用谁」。

1. 想做一个什么样的小工具？

需求非常朴素：

• 输入一段文本（比如用户评论、客服工单）；
• 自动判断它是「正向 / 负向 / 中性」；
• 选做：给出一个大致类别，比如「产品问题 / 物流问题 / 售后问题」。

最终希望变成一个简单的 Web 页面：

• 左边输入框；
• 右边展示：情感结果、类别标签、关键句/关键词。

2. 挑选一个云 NLP 服务

大部分云厂商都会提供类似能力：

• 情感分析（Sentiment Analysis）；
• 文本分类（Text Classification）；
• 关键词提取、实体识别等。

通常接入步骤类似：

1. 注册账号；
2. 在控制台创建一个 NLP 应用 / 项目；
3. 拿到 API Key / Secret / Endpoint；
4. 看一眼文档里示例请求。

示例请求（伪代码）：

POST /nlp/sentiment
Authorization: Bearer <API_KEY>
Content-Type: application/json

{
  "text": "这次发货太慢了，等了一个星期才收到。"
}

响应大概会是：

{
  "sentiment": "negative",
  "confidence": 0.94
}

或者更细一些：

以前做前端上线，经常是这样的：

• 本地 npm run build 打包；
• 用 FTP 或手动拷贝把 dist 丢到服务器；
• 出了问题再手动覆盖回去。

这种方式有几个明显缺点：

• 完全依赖人的操作习惯，出错难追踪；
• 没有固定的「预发布环境」，测试体验不好；
• 回滚麻烦，基本靠「手快」。

这篇文章记录的是：一次给前端项目接上 CI/CD 的实际过程，目标是：

提交代码 → 自动构建 → 部署到预发布 → 人工验证 → 一键上线 & 可快速回滚。

1. 流程目标先画出来

先不管用什么平台（GitHub Actions、GitLab CI、Jenkins…），流程大致分为几步：

1. CI 阶段（持续集成）

   • 安装依赖；
   • 跑 lint / 单测；
   • 打包构建。

2. CD 阶段（持续交付/部署）

   • 构建产物上传到制品库或对象存储；
   • 自动部署到预发布环境；
   • 人工验证无问题后，再部署到生产；
   • 所有版本有记录，可一键回滚。

把这张「大图」先画给团队看，大家对齐预期后，再来谈具体实现。

2. 以 GitHub Actions 为例写一个最小流水线

2.1 基础 CI：安装 + 构建

.github/workflows/ci.yml：

name: Frontend CI

on:
  pull_request:
    branches: [ main, develop ]
  push:
    branches: [ develop ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

      - name: Archive production artifacts
        uses: actions/upload-artifact@v3
        with:
          name: dist
          path: dist

这样每次 PR / 推送到 develop，都能自动帮你检查：