本人的各种服务分别在不同的运营商下，给人以很强的割裂感。比如：
原因在于当初起始购买租赁它们的时候，它们各自的服务都在推广期，价格很能打，久而久之也就沿用至今了。
但还好我自己乱中有序，要统一他们其实也并不难。但如果全部都为一家供应商，那自动化起来也就容易许多，还好我后期增加的服务都尽量使用阿里云了，诸如对象存储阿里云OSS、CICD阿里云云效。
很久以前开始市面上的网站都开始强制使用HTTPS对应的SSL/TLS加密了，还依然只有用HTTP只会是的网站被各种浏览器拦截影响用户体验，打不过就加入。
Postman成立于2012年，最初由Abhinav Asthana在2012年开发为一个Chrome浏览器插件，旨在简化开发者手动测试API的过程1。随着时间的推移，Postman逐渐发展成为一款全面的API开发和测试工具，提供有Chrome扩展插件版和独立的APP，支持多种操作系统，并拥有广泛的用户群体和企业客户。
虽然Postman作为一款接口调试工具，算是非常优秀的了，但一说到使用高级功能要付费就有人坐不住了，决定自己造个轮子免费给大家使用，造福不愿付费的人群。
过往文章点我跳转介绍过一个【极简单的webpack插件开发流程】，但现在的构建工具早已不是webpack一家独大了，Vite在业内的占比也不容小觑。不过没有看过上文的建议先看下，本文相当于上文的“换汤不换药、换汤少换药版本”
前文【构建工具-webpack插件开发1-入门】（点击访问）实现了一个简单插件：在构建完成后生成一个markdown文件，文件里会记录构建时的日期。
作为当代前端工程师，以webpack为首的构建工具基本都用过。使用时稍复杂点儿的项目都要搭配各式各样的插件来达到目的。比如最常见的html-webpack-plugin生成一个空 HTML 文件。
如果现在的插件不能满足我们的业务需求，就需要自己定制了。
本文旨在通过构建一个极简单的webpack插件，让大家可以快速体验下webpack插件的开发流程、架构模式。
以下是实现一个简单插件：在构建完成后生成一个markdown文件，文件里会记录构建时的日期。
// 业务项目根目录新建文件my-webpack-plugin.js
传统的单元测试编写会在初期增加工作量，是广大工程师们都又爱又恨的存在。
不过近几年AI发展迅猛，已经可以主导、辅助生成单元测试了，那肯定是要使用、实践的。
但这不意味着大家可以0基础直接让AI生成，毕竟生成后大家也需要人工code review一下，如果没有单测基础就会一头雾水，那此时大家就可以看我上一篇单测基础文章点击跳转了。
mkdir chrome-demo # 新建项目目录
cd chrome-demo # 进入项目目录
pnpm init -y # 将项目初始化为Node.js项目生成并package.json文件、pnpm-lock.yaml版本锁文件在Clash 中，System Proxy（系统代理）、Mixin（混合规则）、Tun Mode（Tun模式）的选择需根据具体使用场景和需求决定。以下是综合对比及选型建议：
| 模式 | 工作原理 | 适用场景 | 优缺点 |
|---|---|---|---|
| System Proxy | 别被名字欺骗，并非接管所有渠道的流量。通过操作系统代理设置全局管理流量（HTTP/SOCKS代理） | - 需快速启用代理 - 仅需代理浏览器等支持系统代理的应用 | ✅ 简单易用 ❌ 不接管UDP流量，部分应用可能绕过代理（如游戏客户端） |
| Mixin | 动态覆盖主配置文件的规则（YAML格式），实现临时规则调整 | - 需临时调整分流规则（如指定域名/IP走代理/直连） - 避免频繁修改主配置 | ✅ 灵活补充规则 ❌ 需手动维护YAML语法，不改变底层代理逻辑 |
| Tun Mode | 创建虚拟网卡接管系统流量，实现透明代理（支持TCP/UDP全协议） | - 需强制代理所有应用（包括不遵循系统代理的软件） - 需要处理UDP流量 | ✅ 全局接管流量 ❌ 资源占用较高，需安装驱动并重启服务 |
