首先是略跑题的题外话，程序员必须有一个自己的小项目，是不借助 AI 生成代码（起码不是那种完全置之不顾，连原理都不在乎）的项目，前端一样，其他语言也一样。

因为现在 AI 时代，让我自己都觉得惊悚的是，我现在已经变成一个类似于 CEO 的角色了，我已经 6 个月没有怎么书写过代码了。但我必然不是肉食者的管理层。对于靠技术吃饭的人，必须得学习技术，否则就算是在 AI 写代码上，也无法写出更优秀的代码，因为勿在浮沙筑高台！AI 只是催化剂，垃圾催生更多垃圾，精品催生更多精品，要掌握精品的技术。

其次是 3 个我最近搜集的 JS 小技巧，做 SaaS 遇到的。

BroadcastChannel 让你所有页面同步信息

博主我的工作主要是的 SaaS 站。

SaaS 有个锦上添花的功能就是如果一个页面，用户登录了，其他页面自动也转为登录模式（登出也一样）就好了。

其实以我当时的知识储备，我能想到使用 localStorage 这个存，之后 storage 事件（这其实也是个小众知识点）里写上就行。可能有点不优雅，但也可以。但是这个只能传递字符串。

但后来我发现有个目前兼容性还可以的新技术，就是 BroadcastChannel 。

代码就是这样干脆：

// 发送端
const bc = new BroadcastChannel('app_msg');
bc.postMessage({  // 推送登录信息
  action: 'LOGIN',
  uid: 123
});
window.onbeforeunload = () => bc.close();

// 接收端
const bc = new BroadcastChannel('app_msg');  // 注意，统一频道标识
bc.onmessage = ev => {  // 接收
  console.log('接收数据：', ev.data);
};
window.onbeforeunload = () => bc.close();  // 页面销毁关闭通道

这样同域下，不同的标签也就可以通信了，尤其是在登录这个场景下。

其他的如语言切换、黑白主题切换、订单同步、配置同步等等。

PerformanceObserver 更专业的查性能瓶颈

一般的前端程序员，分析网站性能，看看哪里慢了。是使用 console time 或者 dev tool 里的性能分析工具，点来点去分析。

（如果真用在生产环境，其实谷歌的 web-vitals 这个包更全面强大，当然手搓更简洁和自由）

但是在代码里，其实一直有更专业的 performance.getEntries() 这种，能把所有资源（图片、库）的加载完成耗时给收集到。

（俺也很喜欢，把用户的这些数据收集起来，直接上报给我的服务器，让我好分析在用户端，我的 SaaS 在不同国家、设备、网速下会怎么样）

但这个有缺点，就是很多指标不能很好地实时拿到（属于事后诸葛亮），必须定时轮询。

然后我发现了个 PerformanceObserver ，这个可以。只要一有新资源出现，它就自动通知。

比如计算 LCP （什么时候加载完）、CLS （页面加载时会不会乱跳）

let lcp, cls = 0;

// LCP
new PerformanceObserver(list => {
  lcp = list.getEntries().at(-1);
}).observe({ type: 'largest-contentful-paint', buffered: true });

// CLS
new PerformanceObserver(list => {
  for (const e of list.getEntries()) {
    if (!e.hadRecentInput) cls += e.value;
  }
  console.log('CLS:', cls);
}).observe({ type: 'layout-shift', buffered: true });

// 页面离开时读取 LCP
addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden' && lcp) {
    console.log('LCP:', lcp.startTime);
  }
});

这样就可以直接在代码里获取实时的 CLS 和 LCP 了。

之后你拿到数据，可以开发时充分分析数据、放生产环境客户端上报服务器了。

AbortController 防止异步请求滥用

不管做什么软件，都有一个事儿让人很头疼，就是用户如果单击了很多请求，但是突然又切换页面了，那....

旧的请求还在路上，如果等它们返回数据，然后可能就把用户的新页面又覆盖了（或者也浪费）。

以前，一些请求我会自己写一些变量来检测，防止这种事，可是一个一个写真的太麻烦。后来一个老外告诉我有个 AbortController 。

用法很简单：

// 创建
const ctrl = new AbortController();

fetch('/api/data', {
  signal: ctrl.signal
})
.then(res => res.json())
.then(data => {
  console.log(data);
})
.catch(err => {
  if (err.name === 'AbortError') {  // 判断是否为主动取消请求
    console.log('请求已取消');
  } else {
    console.error(err);
  }
});

// 主动取消当前请求
ctrl.abort();

以后的请求都这样写，这样你可以在该取消请求的时候，一键取消，以防后患。