2024年，Chrome将要正式禁用第三方Cookie了，这个变化对Web开发者来说是非常重要的，因为它将改变开发者如何设计网站以及如何搜集和使用用户数据。这是怎么一回事，到底有什么具体影响？

什么是Cookie？

随着互联网技术的发展，我们的生活变得越来越数字化，网上购物、社交、阅读新闻成为日常。而在这个数字化的世界中，Cookie扮演了一个不可或缺的角色。

Cookie是一种由浏览器保存在用户电脑上的小块数据，用来帮助网站记住用户的信息和设置。网站可以在前端直接操作Cookie，也可以根据服务器返回的指令设置Cookie，当浏览器请求同一服务器时相应的Cookie会被回传。Cookie让网站能够记住用户的登录状态、购物车中的商品、以及个性化设置等，极大地提升了用户体验。

第三方Cookie是咋回事？

然而，Cookie并非只有一种。其中，第三方Cookie与网站直接设置的第一方Cookie不同，它们通常由第三方广告商或网站分析服务设置。网站一般通过在前端页面引入第三方的Javascript程序文件来实现这种能力。

用于网站分析时，Cookie可以收集和存储有关用户访问网站的数据，如用户的浏览历史、停留时间、点击行为等。这些数据对于网站运营者来说非常有价值，可以帮助他们了解用户的行为和兴趣，优化网站的设计和功能，提升用户的体验。

用于广告时，Cookie可以用来追踪用户在不同网站上的行为，以便提供个性化广告和内容。这种广泛的追踪能力让广告商能够了解用户的喜好和习惯，从而推送更加精准的广告。

为什么要禁用第三方Cookie？

但第三方Cookie也引发了隐私方面的担忧。许多用户和隐私倡导者认为，广告商利用Cookie追踪用户的行为侵犯了个人隐私。

很多同学应该有这样的体验：你在某个网站搜索了某个东西，然后访问其它网站或服务时，网页会向你展示之前搜索过的类似东西。基于某些原因，有时候我们并不想这样被跟踪。

这种担忧导致了对第三方Cookie的禁用呼声。同时隐私担忧不仅仅来自于用户和隐私倡导者，也来自于法规如欧盟的通用数据保护条例（GDPR）和加州消费者隐私法案（CCPA）这样的法律要求。

为了应对这一问题，苹果公司在其Safari浏览器中率先禁用了第三方Cookie，微软和Mozilla也采取了类似措施。

谷歌的行动计划是什么样的？

但是，作为浏览器市场占有率第一的谷歌，却迟迟没有明显的动作，遭到了不少人的非议和批评。

为了解决这些问题，谷歌提出了“隐私沙盒”（Privacy Sandbox）计划，旨在开发一系列新的技术，既能保护用户隐私，又能支持广告商进行有效的广告投放。

想象一下，如果有一个中立的场所，既能让你安心地存放你的个人物品，又能让有需要的人在不侵犯你隐私的情况下了解你的需求，这就是隐私沙盒的理念。

例如，谷歌提出的FLoC（Federated Learning of Cohorts）技术，就是将用户分群，而非单独追踪个人行为，从而在保护个人隐私的同时提供群体级的广告定位。

作为市场份额最大的浏览器，谷歌计划在2024年1月开始逐步禁用第三方Cookie，在2024年第三季度完成第三方Cookie的全面禁用。

禁用导致的问题有哪些？

禁用第三方 Cookie 对网站主、广告商和用户都会产生一系列影响。针对不同群体的影响及解决方案如下：

网站主

第三方 Cookie 的禁用可能会让网站主失去对用户行为的深入分析能力，因为他们将不能再依靠第三方 Cookie 来追踪用户在多个网站上的活动。这可能会影响到网站的个性化服务和广告定位的准确性，进而影响网站收入。

解决方案：网站主可以更多地依赖第一方 Cookie，即直接由网站域设置和读取的 Cookie。这些 Cookie 可以帮助网站主跟踪用户在自己网站上的行为，而不越过隐私边界。此外，网站主可以通过提供更多的价值服务来鼓励用户主动分享信息。

对于拥有多个域名的网站主来说，可以使用同一个根域名来设置Cookie，这样在根域名下的所有子域名都可以访问这些Cookie，这种方法仍然在用户隐私保护的框架内。如果网站主拥有多个相关联的服务，可以实施更安全的单点登录解决方案，比如使用会话令牌和OAuth等协议。

广告商

广告商将难以像过去那样追踪用户在整个互联网的行为，从而无法进行精准的广告定向，这可能导致广告效果下降和收入减少。

解决方案：谷歌提出的隐私沙盒计划中，Event Conversion Measurement API 是一种技术解决方案，它允许广告商在不侵犯用户隐私的情况下测量广告转化率。此外，广告商还可以利用机器学习等技术，通过分析大量的匿名化和聚合数据来预测用户兴趣。不过广告商也有机会使用一些更隐蔽的技术追踪手段来保持原有的业务模式，具体一些技术下文会提到。

用户

用户的隐私得到更好的保护，但可能会失去一些基于个性化广告的便利性，例如推荐系统的准确性可能会下降。

解决方案：用户可以获得更多的隐私控制权，例如通过浏览器设置来决定哪些数据可以被网站使用。同时，随着技术的发展，用户可能会遇到更多基于隐私保护的个性化体验，例如使用本地算法来进行内容推荐，而不需要将个人数据传输到服务器。

谷歌真的做好了吗？

尽管谷歌提出了Privacy Sandbox这样的计划，希望在不依赖个人用户信息的情况下，仍然能够支持广告生态系统，但实际上这个计划也遭到了一些批评。批评者认为，这些新提出的技术可能仍然允许用户被追踪，只不过追踪的方式更加隐蔽了。

例如，FLoC的提出本意是为了代替传统的个人定向广告，它通过对用户进行群组化来推送广告，这样不会直接暴露个人的行为数据。但问题在于，群组化的数据仍然可能被用来间接识别和追踪个人，特别是当某个群组里的用户数量不多时。这就导致了一种新形式的隐私问题，即“群组隐私”的泄露。

还有广告服务商仍可能通过一些技术手段突破隐私限制，比如通过网站转发、Canvas指纹技术、网络信标、用户代理字符串、本地存储和ETag跟踪等。

此外，一些隐私倡导者还担心，谷歌作为一个广告公司，其提出的隐私解决方案可能偏向于维护其在在线广告市场中的主导地位。他们认为，谷歌有动机设计一套系统，搜集用户在搜索、YouTube和其他谷歌服务上的行为数据，使得自家的广告网络相比其他竞争对手拥有优势。而这可能会影响到广告市场的公平竞争，甚至可能对开放网络生态系统构成威胁。

总的来说，谷歌在隐私问题上的努力是一个积极的开始，但隐私保护的路还很长。而对于技术人员而言，理解这些变化和挑战，以及如何在保护用户隐私的同时提供优质服务，将是未来发展的一个重要课题。

关注萤火架构，提升技术不迷路！

前言

很多时候，老是质疑反问自己，在空闲时间都在干嘛呢？是沉迷于看动漫、美女视频，打游戏？还是在追求更有意义的事呢？自我回答，没错我是属于前者了（dog），然后前后左右思考，还是决定找一些事做，不能一直这么荒废了，起码做一些是一些，积少成多！但是能做什么呢？这又引起我这不聪明的大脑深深的思考，是从自己从事的职位来，还是从自己的兴趣来呢？然后在这段迷茫的时间一直在寻找中，突然有一天看到别人的文章或视频感触深刻，最后还是敲定做项目！然后就着手开始准备做起来，就这么愉快决定行动起来了，奥利给！

于是利用上班摸鱼时间和下班空闲的时间开始行动起来~

起源

在空闲的摸鱼时间里，我经常喜欢看别人写的文章，读完一篇又一篇，大多数时候都会感叹并羡慕。然鹅，特别是对于某些事情，我会有特别深的感触。因为有时候的情绪只是在特定时刻被触发的，所以我想记录下当时的触发感受和情绪。然后我就去寻找相关的插件，结果找到了一个相当不错的插件。试用了一番后，发现效果还不错，于是我决定将关注点留在这里，尝试着制作这类插件，看看自己做的的效果如何。有时候我在想，为什么要费力自己创建一个插件呢？毕竟市面上已经有现成的插件了，为什么不用呢？然而，答案很明了：一是想要找点事情做，二是想要提升一下自己的技能水平。于是，这样的动力激励着我行动起来。

需求

产品需求其实很明确，因为从我的角度来看已经有现成的产品可供参考，然后只需根据个人需求进行定制。因此，产品的主要目的是为了方便我们的生活。

因此，一个产品的设计应当能够满足不同用户的需求，以提供更好的使用体验。这里着重考虑我自己个人使用，因为每个人的习惯和偏好都不尽相同。

收集的功能需求：

• 对内容进行划线


• 记录想法/感想


• 统计列表数据


• 预览原文（主要是针对文章）


• 拷贝（划线、原文、Markdown）内容


• 下载（划线TXT、原文TXT、原文Markdown）内容

目前第一版只涵盖了这些功能需求（感谢ChatGPT，它帮助解决了我作为菜狗的许多问题），后续将根据需要情况进行调整和完善~

下面是完成的功能截图：

突然发现我开发这个插件还有一个小用处哈哈哈，针对类似我这种不会写文章格式的小白来说，有时候真的不知道该如何开始写。但有一个现成的文章作为参考，真是太棒了！它不仅能够给我提供灵感，还能够帮助我了解文章的结构和写作风格，让我更加自信地面对写作挑战！

拷贝的文章markdown格式：

最后打算发版到chrome，目前正在审核中~

总结

可能我是一个老老实实上班族的一个菜狗，但是勇于尝试也挺好的，毕竟在尝试中，我能够不断学习、成长，迎接新的挑战，拓展自己的能力和视野。

历经三个月的努力，终于完成了第一版。其实本来应该在一个多月内完成的，但中途我可能有些懒惰哈哈。虽然我觉得自己做的东西还不尽如人意，但从某种角度来说，至少我迈出了那一步。哪怕是简单的东西，也是通过自己制造出来的，多多少少都有一些成就感。而且，这个过程也丰富了我的技术栈。因此，我在开始思考如何完成一个要好的项目，是否可以继续打造一款完整的产品，让人们使用，如果有人使用我的产品，我也会感到非常满足！

最后思考

1、有时候，当你不知道该做什么时，一定不要让自己闲着。我深以为然，这句话给了我很大启发，我记得是在阅读一篇文章时被深深触动的。

2、有时候，想得再多也不如行动来得有效。即使方向错误，但这也是我从中获得的宝贵经验。总结经验才能不断进步。

3、时间是可以挤出来的，再忙再累也会有时间的。看个人是否愿意付诸行动，但也要适当放松，保持身心健康。

第一次写文章还是有点乱七八糟的，但这也是成长的一部分。还得继续努力，不断学习，能够更好地传达我的想法和观点!

RTSP流媒体播放器

前言：因公司业务需求，研究了下在web端播放rtsp流视频的方案，过程很曲折，但也算是颇有收获。

播放要求

• web网页播放或者手机小程序播放


• 延迟小于500ms


• 支持多路播放


• 免费

舍弃的方案

• 【hls】延时非常高，有时候能达到几十秒，实时性场景直接pass


• 【转rtmp】需要借助flash插件


• 【转图片帧】需要后端借助工具将rtsp视频流每一帧转成图片，再通过websocket协议实时传输到前端，前端用canvas绘制，这种方法对后端转流要求较高，每张图片如果太大会掉帧，延时也不稳定

思路尝试

1、 flvjs + ffmpeg + websocket + node

这套方案的核心为 BiLiBiLi 开源的 flvjs，原理是在后端利用 转流工具 FFmpeg 将 rtsp流 转成 flv流，然后通过 websocket 传输 flv流，在利用 flvjs 解析成可以在浏览器播放的视频。

flv不支持ios 请自行取舍

参考文章

2、WebRTC

Webrtc是前端的技术，后端使用有点困难，原理是将 rtsp流 转成 webrtc流，直接在video中播放（需要浏览器支持webrtc）

如何将rtsp转成webrtc 基于两个工具实现

参考链接1 :webrtcstreamer.js 前端实现

参考链接2 : mediamtx转流

3、jsmpeg.js + ffmpeg + websocket + node

这种方案是我测试过免费方案中效果最好的，原理是在后端利用 转流工具 FFmpeg 将 rtsp流 转成 图片流，然后通过 websocket 传输 图片，在利用 jsmpeg.js 绘制到canvas上显示

优点：

• 可以通时兼容多路视频，且对浏览器内存占用不会太高


• 延迟还可以 测试在300-1000ms左右

缺点：

• 多路无法使用主码流 会把浏览器卡死


• 清晰度不够，画面大概在720p左右

前后端代码放jsbin了 地址 ：jsbin.com/hazacak/edi…

注意
使用时请下载ffmpeg 并把ffmpeg添加值环境变量

4 、终极方案：ZLMediaKit +h265webjs

该方案应该是此类问题的终极解决方案（个人认为，有好的方案请共享）

原理：

可以看到ZlMediaKit支持把各种流进行转换输出，我们可以使用输出的流进行播放

为了便捷 推荐你使用ZLM文档提供的Docker镜像，同时ZLM提供各种的restful AP供你使用，可以转流，推流等等，具体查看文档中的 restful API部分内容

其中需要注意的是 API中的secret 在镜像文件 /opt/mdeia/conf 文件夹下 请手动复制出来 每次构建镜像 改值会变化

另外 推荐一个ZLM 的管理界面 github.com/1002victor/…

只需要把代码全部复制到 www目录下即可放心食用

前端部分：

因为前端部分相关的视频库都存在部分协议不支持，没办法完全进行测试

故选择了ZLM官方推荐的 h265webjs这个播放库，经过测试，便捷容易，可安全食用
地址：

• h265webjs文档地址


• ZLMediaKit文档地址

背景

项目上有个更改时区的全局组件，同时还有一个可以更改时区的局部组件，想让更改时区的时候能联动起来，实时响应起来。

其实每次设置完时区的数据之后是存在了前端的 localStorage 里边，时间组件里边也是从 localStorage 拿去默认值来回显。如果当前页面不刷新，那么时间组件就不能更新到最新的 localStorage 数据。

怎么才能让 localStorage 存储的数也变成响应式呢？

实现

失败的案例 1

首先想到的是按照下边这种方式做，

useEffect(()=>{ 

    console.log(11111, localStorage.getItem('timezone')) 

},[localStorage.getItem('timezone')])

得到的测试结果肯定是失败的，但是为啥失败？我们也应该知道一下。查了资料说，使用 localStorage.getItem('timezone') 作为依赖项会导致每次渲染都重新计算依赖项，这不是正确的做法。

具体看一下官方文档：useEffect(setup, dependencies?) 

在此说一下第二个参数 dependencies：

可选 dependencies：setup 代码中引用的所有响应式值的列表。响应式值包括 props、state 以及所有直接在组件内部声明的变量和函数。如果你的代码检查工具 配置了 React，那么它将验证是否每个响应式值都被正确地指定为一个依赖项。依赖项列表的元素数量必须是固定的，并且必须像 [dep1, dep2, dep3] 这样内联编写。React 将使用 Object.is 来比较每个依赖项和它先前的值。如果省略此参数，则在每次重新渲染组件之后，将重新运行 Effect 函数。

• 如果你的一些依赖项是组件内部定义的对象或函数，则存在这样的风险，即它们将 导致 Effect 过多地重新运行。要解决这个问题，请删除不必要的 对象 和 函数 依赖项。你还可以 抽离状态更新 和 非响应式的逻辑 到 Effect 之外。

如果你的 Effect 依赖于在渲染期间创建的对象或函数，则它可能会频繁运行。例如，此 Effect 在每次渲染后重新连接，因为 createOptions 函数 在每次渲染时都不同：

function ChatRoom({ roomId }) {

  const [message, setMessage] = useState('');



  function createOptions() { // 🚩 此函数在每次重新渲染都从头开始创建

    return {

      serverUrl: serverUrl,

      roomId: roomId

    };

  }



  useEffect(() => {

    const options = createOptions(); // 它在 Effect 中被使用

    const connection = createConnection();

    connection.connect();

    return () => connection.disconnect();

  }, [createOptions]); // 🚩 因此，此依赖项在每次重新渲染都是不同的

  // ...

}

失败的案例 2

一开始能想到的是监听，那就用 window 上监听事件。

在 React 应用中监听 localStorage 的变化，可以使用 window 对象的 storage 事件。这个事件在同一域名的不同文档之间共享，当某个文档修改 localStorage 时，其他文档会收到通知。

写代码...

// useRefreshLocalStorage.js

import { useState, useEffect } from 'react';



const useRefreshLocalStorage = (key) => {

  const [storageValue, setStorageValue] = useState(

    localStorage.getItem(key)

  );

  

  useEffect(() => {

    const handleStorageChange = (event) => {

      if (event.key === key) {

        setStorageValue(event.newValue)

      }

    };



    window.addEventListener('storage', handleStorageChange);



    return () => {

      window.removeEventListener('storage', handleStorageChange);

    };

  }, [key]);

  

  return [storageValue];

};



export default useRefreshLocalStorage;

使用方式：

// useTimezone.js

import { useState, useEffect } from "react";



import { getTimezone, timezoneKey } from "@/utils/utils";

import useRefreshLocalStorage from "./useRefreshLocalStorage";



function useTimezone() {

  const [TimeZone, setTimeZone] = useState(() => getTimezone());

  const [storageValue] = useRefreshLocalStorage(timezoneKey);



  useEffect(() => {

    setTimeZone(() => getTimezone());

  }, [storageValue]);



  return [TimeZone];

}



export default useTimezone;

经过测试，失败了，没有效果！！！那到底怎么回事呢？哪里出现问题了？查阅��料经过思考，可能出现的问题的原因有：只能监听同源的两个页面之间的 storage 变更，没法监听同一个页面的变更。

成功的案例

import { useState, useEffect } from "react";



// 自定义 Hook，用于监听 localStorage 中指定键的变化

function useRefreshLocalStorage(localStorage_key) {

  // 检查 localStorage_key 是否有效

  if (!localStorage_key || typeof localStorage_key !== "string") {

    return [null];

  }

  

  // 创建一个状态变量来保存 localStorage 中的值

  const [storageValue, setStorageValue] = useState(

    localStorage.getItem(localStorage_key)

  );



  useEffect(() => {

    // 保存原始的 localStorage.setItem 方法

    const originalSetItem = localStorage.setItem;

    // 重写 localStorage.setItem 方法，添加事件触发逻辑

    localStorage.setItem = function(key, newValue) {

      // 创建一个自定义事件，用于通知 localStorage 的变化

      const setItemEvent = new CustomEvent("setItemEvent", {

        detail: { key, newValue },

      });

      // 触发自定义事件

      window.dispatchEvent(setItemEvent);

      // 调用原始的 localStorage.setItem 方法

      originalSetItem.apply(this, [key, newValue]);

    };



    // 事件处理函数，用于处理自定义事件

    const handleSetItemEvent = (event) => {

      const customEvent = event;

      // 检查事件的键是否是我们关心的 localStorage_key

      if (event.detail.key === localStorage_key) {

        // 更新状态变量 storageValue

        const updatedValue = customEvent.detail.newValue;

        setStorageValue(updatedValue);

      }

    };



    // 添加自定义事件的监听器

    window.addEventListener("setItemEvent", handleSetItemEvent);



    // 清除事件监听器和还原原始方法

    return () => {

      // 移除自定义事件监听器

      window.removeEventListener("setItemEvent", handleSetItemEvent);

      // 还原原始的 localStorage.setItem 方法

      localStorage.setItem = originalSetItem;

    };

    // 依赖数组，只在 localStorage_key 变化时重新运行 useEffect

  }, [localStorage_key]);



  // 返回当前的 storageValue

  // 为啥没有返回 setStorageValue ？

  // 因为想让用户直接操作自己真实的 “setValue” 方法，这里只做一个只读。

  return [storageValue];

}



export default useRefreshLocalStorage;

具体的实现步骤如上，每一步也加上了注释。

接下来就是测试了，

useTimezone 针对 timezone 数据统一封装，

// useTimezone.js

import { useState, useEffect } from "react";



import { getTimezone, timezoneKey } from "@/utils/utils";

import useRefreshLocalStorage from "./useRefreshLocalStorage";



function useTimezone() {

  const [TimeZone, setTimeZone] = useState(() => getTimezone());

  const [storageValue] = useRefreshLocalStorage(timezoneKey);



  useEffect(() => {

    setTimeZone(() => getTimezone());

  }, [storageValue]);



  return [TimeZone];

}



export default useTimezone;

具体的业务页面组件中使用，

// 页面中

// ...

import useTimezone from "@/hooks/useTimezone";



export default (props) => {

  // ...

  const [TimeZone] = useTimezone();

  

  useEffect(()=>{ 

      console.log(11111, TimeZone) 

  },[TimeZone)

}

测试结果必须是成功的啊！！！

小结

其实想要做到该效果，用全局 store 状态管理也能做到，条条大路通罗马嘛！不过本次需求由于历史原因一直使用的是 localStorage ，索性就想着 如何让 localStorage 存储变为响应式 ？

不知道大家还有什么更好的方法吗？

前言

在 JavaScript 开发中，细节处理不当往往会导致意想不到的运行时错误，甚至让应用崩溃。可能你昨天上完线还没问题，第二天突然一大堆人艾特你，你就说你慌不慌。

来吧，咱们来捋一下怎么做才能让你的代码更健壮，即使后端数据出问题了咱前端也能稳得一批。

解构失败报错

不做任何处理直接将后端接口数据进行解构

const handleData = (data)=> {

  const { user } = data;

  const { id, name } = user;

}

handleData({})



VM244:3 Uncaught TypeError: Cannot destructure property 'id' of 'user' as it is undefined.

解构赋值的规则是，只要等号右边的值不是对象或数组，就先将其转为对象(装箱)。由于 undefined 、null 无法转为对象，所以对它们进行解构赋值时就会报错。

所以当 data 为 undefined 、null 时候，上述代码就会报错。

第二种情况，虽然给了默认值，但是依然会报错

const handleData = (data)=> {

  const { user = {} } = data;

  const { id, name } = user;

}

handleData({user: null})

ES6 内部使用严格相等运算符（===）判断一个变量是否有值。所以，如果一个对象的属性值不严格等于 undefined ，默认值是不会生效的。

所以当 props.data 为 null，那么 const { name, age } = null 就会报错！

good：

const handleData = (data)=> {

  const { user } = data;

  const { id, name } = user || {};

}

handleData({user: null})

数组方法调用报错

从接口拿回来的数据直接用当成数组来用

const handleData = (data)=> {

  const { userList } = data;

  const newList = userList.map((item)=> item.name)

}

handleData({userList: null})

handleData({userList: 123})



VM394:3 Uncaught TypeError: userList.map is not a function

那么问题来了，如果 userList 不符合预期，不是数组时必然就报错了，所以最好判断一下

good：

const handleData = (data)=> {

  const { userList } = data;

  if(Array.isArray(userList)){

    const newList = userList.map((item)=> item.name)

  }

}

handleData({userList: 123})

遍历对象数组报错

遍历对象数组时也要注意 null 或 undefined 的情况

const handleData = (data)=> {

  const { userList } = data;

  const newList = userList.map((item)=> item?.name)

}

handleData({userList: [ null, undefined ]})



VM547:3 Uncaught TypeError: Cannot read properties of null (reading 'name')

一旦数组中某项值是 undefined 或 null，那么 item.name 必定报错，可能又白屏了。

good：

const handleData = (data)=> {

  const { userList } = data;

  const newList = userList.map((item)=> item?.name)

}

handleData({userList: [null]})

但是如果是这种情况就不good了

const handleData = (data)=> {

  const { userList } = data;

  const newList = userList.map((item)=> `用户id是${item?.id}，用户名字是${item?.name},用户年龄是${item?.age}岁了`);

}

handleData({userList: [null]})

? 可选链操作符，虽然好用，但也不能滥用。item?.name 会被编译成 item === null || item === void 0 ? void 0 : item.name，滥用会导致编译后的代码size增大。

good：

const handleData = (data)=> {

  const { userList } = data;

  const newList = userList.map((item)=> {

    const { id, name, age } = item || {};

    return `用户id是${id}，用户名字是${name},用户年龄是${age}岁了`

  });

}

handleData({userList: [null]})

当可选链操作符较多的情况时无论是性能还是可读性都明显上面这种方式更好。

复习一下装箱

大家可以思考一下，以下代码会不会报错

const handleData = (data)=> {

  const { userList } = data;

  const newList = userList.map((item)=> item.name)

}

handleData({userList: ['', 123]})

是不会报错的，因为在 JavaScript 中，当你在一些基本类型上直接访问属性时这些类型会被自动临时转换成它们对应的对象类型。这种转换称为“装箱”（boxing）。例如：

• ('').name
  
  

  空字符串被临时转换成一个字符串对象。由于没有名为 name 的属性，所以它返回 undefined，但不会报错。

  
  

  let str = "hello";
  
  console.log(str.length); // 5
  
  

  
  

  在这里，str.length 实际上是在字符串对象上调用的，而不是直接在基本类型字符串上。JavaScript 引擎在幕后将字符串 "hello" 装箱为 String 对象，因此可以访问 length 属性。



• (123).name
  
  

  数字 123 被临时转换成一个数字对象。由于没有名为 name 的属性，所以它返回 undefined，但不会报错。

  
  

  let num = 123;
  
  console.log(num.toFixed(2)); // "123.00"
  
  

  
  

  num.toFixed(2) 调用了数字对象的 toFixed 方法。JavaScript 将数字 123 装箱为 Number 对象。



• (null).name
  
  

  null 是一个特殊的基本类型，当尝试访问其属性时会报错，因为 null 不能被装箱为对象。

  
  

  try {
  
    const name = (null).name; // TypeError: Cannot read property 'name' of null
  
  } catch (error) {
  
    console.error(error);
  
  }
  
  

  
  


• (undefined).name
  
  

  undefined 也不能被装箱为对象。

  
  

  try {
  
    const name = (undefined).name; // TypeError: Cannot read property 'name' of undefined
  
  } catch (error) {
  
    console.error(error);
  
  }
  
  

  
  

JavaScript 中的基本类型包括：

string

number

boolean

symbol

bigint

null

undefined

对应的对象类型是：

String

Number

Boolean

Symbol

BigInt

装箱的工作原理：

当你访问基本类型的属性或方法时，JavaScript 会自动将基本类型装箱为其对应的对象类型。这个临时的对象允许你访问属性和方法，但它是短暂的，一旦属性或方法访问完成，这个对象就会被销毁。

需要注意的是，null 和 undefined 没有对应的对象类型，不能被装箱。所以访问它们的属性或方法会直接报错！所以时刻警惕 null 和 undefined 这俩坑。

使用对象方法时报错

同理，只要变量能被转成对象，就可以使用对象的方法，但是 undefined 和 null 无法转换成对象。对其使用对象方法时就会报错。

const handleData = (data)=> {

  const { user } = data;

  const newList = Object.entries(user);

}

handleData({user: null});



VM601:3 Uncaught TypeError: Cannot convert undefined or null to object

下面这两种优化方式都可

good:

const handleData = (data)=> {

  const { user } = data;

  const newList = Object.entries(user || {})

}

handleData({user: null})

good:

/**

 * 判断给定值的类型或获取给定值的类型名称。

 *

 * @param {*} val - 要判断类型的值。

 * @param {string} [type] - 可选，指定的类型名称，用于检查 val 是否属于该类型。

 * @returns {string|boolean} - 如果提供了 type 参数，返回一个布尔值表示 val 是* 否属于该类型；如果没有提供 type 参数，返回 val 的类型名称（小写）。

 *

 * @example

 * // 获取类型名称

 * console.log(judgeDataType(123)); // 输出 'number'

 * console.log(judgeDataType([])); // 输出 'array'

 *

 * @example

 * // 判断是否为指定类型

 * console.log(judgeDataType(123, 'number')); // 输出 true

 * console.log(judgeDataType([], 'array')); // 输出 true

 */

function judgeDataType(val, type) {

  const dataType = Object.prototype.toString.call(val).slice(8, -1).toLowerCase();

  return type ? dataType === type : dataType;

}



const handleData = (data)=> {

  const { user } = data;

  // 判断是否为对象

  if(judgeDataType({}, "object")){

    const newList = Object.entries(user || {})

  }

}

handleData({user: null})

async/await 报错未捕获

这个也是比较容易犯且低级的错误

import React, { useState } from 'react';



const List = () => {

  const [loading, setLoading] = useState(false);

  const getData = async () => {

    setLoading(true);

    const res = await fetchListData();

    setLoading(false);

  }

}

如果 fetchListData() 执行报错，页面就会一直在加载中，所以一定要捕获一下。

good:

const List = () => {

  const [loading, setLoading] = useState(false);

  const getData = async () => {

    setLoading(true);

    try {

      const res = await queryData();

      setLoading(false);

    } catch (error) {

      setLoading(false);

    }

  }

}

当然如果觉得这种方式不优雅，用 await-to-js 库或者其他方式都可以，记得捕获就行。

JSON.parse报错

如果传入的不是一个有效的可被解析的 JSON 字符串就会报错啦。

const handleData = (data)=> {

  const { userStr } = data;

  const user = JSON.parse(userStr);

}

handleData({userStr: 'fdfsfsdd'})





16:06:57.521 VM857:1 Uncaught SyntaxError: Unexpected token 'd', "fdfsfsdd" is not valid JSON

这里没必要去判断一个字符串是否为有效的 JSON 字符串，只要利用 trycatch 来捕获错误即可。

good:

const handleData = (data)=> {

  const { userStr } = data;

  try {

    const user = JSON.parse(userStr);

  } catch (error) {

    console.error('不是一个有效的JSON字符串')

  }

}

handleData({userStr: 'fdfsfsdd'})

动态导入模块失败报错

动态导入某些模块时，也要注意可能会报错

const loadModule = async () => {

    const module = await import('./dynamicModule.js');

    module.doSomething();

}

如果导入的模块存在语法错误、网络或者跨域问题、文件不存在、循环依赖、甚至文件非常大导致内存不足、模块内的运行时错误等都有可能阻塞后续代码执行。

good:

const loadModule = async () => {

  try {

    const module = await import('./dynamicModule.js');

    module.doSomething();

  } catch (error) {

    console.error('Failed to load module:', error);

  }

}

API 兼容性问题报错

fetch('/api/data')

  .then(response => response.json())

  .then(data => console.log(data))

  .catch(error => console.error('Error:', error));

低版本 Node 不支持 fetch，需要更高兼容性的场景使用 axios 等更好。

其他包括小程序开发，web开发等也同理，如果使用了某些不支持的 es 新特性或者较新版本的平台才支持的api也会导致直接报错，使用时做好判断或直接用兼容性更好的写法。

框架在编译时已经帮我们解决了大部分的兼容性问题，但是有些场景还需额外注意。

内存溢出崩溃

滥用内存缓存可能会导致内存溢出

const cache = {};



function addToCache(key, value) {

  cache[key] = value;

  // 没有清理机制，缓存会无限增长

}

避免闭包持有大对象的引用

function createClosure() {

  const largeData = new Array(1000000).fill('x');



  return function() {

    console.log(largeData.length);

  };

}



const closure = createClosure();

// largeData 现在被闭包引用会一直存活在内存中，即使不再直接使用



closure = null; // 手动解除引用

记得清除定时器和事件监听器

// React

useEffect(() => {

  const timeoutId = setTimeout(() => {

    // 一些操作

  }, 1000);



  return () => clearTimeout(timeoutId);

}, []);

function setupHandler() {

  const largeData = new Array(1000000).fill('x');

  const handler = function() {

    console.log(largeData.length);

  };



  document.getElementById('myButton').addEventListener('click', handler);



  return function cleanup() {

    document.getElementById('myButton').removeEventListener('click', handler);

  };

}



const cleanup = setupHandler();

// 在适当的时候调用

// cleanup();

还有深度递归，JSON.parse() 解析超大数据等都可能会对内存造成压力。

总结

以上列举了js在运行时可能会发生错误而导致的应用崩溃的一些边界情况，这些都是在开发时不那么容易察觉，eslint等静态检查工具也无能为力的场景，当然如果用typescript的话还是可以帮助我们避免大部分坑的，如果不用 ts 的话就不可避免的需要考虑这些情况才能写出健壮的代码。

边界场景的容错一定要做，原则上不信任任何外部输入数据的存在性和类型，历史经验告诉我们，不做容错出错只是早晚的事。

帮别人review代码的时候也可以参考以上清单，如果大家还有补充欢迎讨论，最后祝各位大佬没有bug。

关联精彩文章：# 改进tabs组件切换效果，丝滑的动画获得一致好评~

背景

今天，同事看到了我一段遍历读取对象key的代码后，居然嘲笑我技术菜（虽然我确实菜）

const person = {

  name: '员工1',

  age: 30,

  profession: 'Engineer'

  // ....

};



// 使用 for 循环读取对象的键

const keys = Object.keys(person);

for (let i = 0; i < keys.length; i++) {

  const key = keys[i];

  const value = person[key];

  console.log(key + ': ' + value);

}

我说，用for循环读取对象的key不对吗，他二话不说直接给我改代码

const person = {

  name: '员工1',

  age: 30,

  profession: 'Engineer'

};



Object.keys(person).forEach(key => {

  console.log(key + ': ' + person[key]);

});

然后很装的走了......钢铁直男啊！我很生气，我这个人比较较劲，我一定要把Object.keys吃透！

Object.keys的基础用法

语法

Object.keys 是 JavaScript 中的一个方法，用于获取对象自身的可枚举属性名称，并以数组形式返回。

Object.keys(obj)

• 参数：要返回其枚举自身属性的对象


• 返回值：一个表示给定对象的所有可枚举属性的字符串数组

不同入参的返回值

• 处理对象，返回可枚举的属性数组

let person = {name:"张三",age:25,address:"深圳",getName:function(){}}



Object.keys(person) 



// ["name", "age", "address","getName"]

• 处理数组，返回索引值数组

let arr = [1,2,3,4,5,6]

Object.keys(arr) 

// ["0", "1", "2", "3", "4", "5"]

• 处理字符串，返回索引值数组

let str = "saasd字符串"

Object.keys(str) 

// ["0", "1", "2", "3", "4", "5", "6", "7"]

Object.keys的常用技巧

Object.keys在处理对象属性、遍历对象和动态生成内容时非常有用。

遍历对象属性

当你需要遍历一个对象的属性时，Object.keys 可以将对象的所有属性名以数组形式返回，然后你可以使用 forEach 或 for...of 来遍历这些属性名。

示例：

const person = {

  name: '员工1',

  age: 30,

  profession: 'Engineer'

};



Object.keys(person).forEach(key => {

  console.log(key + ': ' + person[key]);

});

输出：

name: 员工1

age: 30

profession: Engineer

获取对象属性的数量

可以使用 Object.keys 获取对象的属性名数组，然后通过数组的 length 属性来确定对象中属性的数量。

示例：

const person = {

  name: '员工2',

  age: 30,

  profession: 'Engineer'

};



const numberOfProperties = Object.keys(person).length;

console.log(numberOfProperties); // 输出: 3

过滤对象属性

可以使用 Object.keys 来获取对象的属性名数组，然后使用数组的 filter 方法来筛选属性名，从而创建一个新的对象。

示例：

const person = {

  name: '员工3',

  age: 30,

  profession: '钢铁直男'

};



const filteredKeys = Object.keys(person).filter(key => key !== 'age');

const filteredPerson = {};



filteredKeys.forEach(key => {

  filteredPerson[key] = person[key];

});



console.log(filteredPerson); // 输出: { name: '员工3', profession: '钢铁直男' }

检查对象是否为空

可以通过检查 Object.keys 返回的数组长度来确定对象是否为空。

示例：

const emptyObject = {};

const nonEmptyObject = { name: '讨厌的人' };



function isEmpty(obj) {

  return Object.keys(obj).length === 0;

}



console.log(isEmpty(emptyObject));  // 输出: true

console.log(isEmpty(nonEmptyObject)); // 输出: false

深拷贝对象

虽然 Object.keys 本身并不能进行深拷贝，但它可以与其他方法结合使用来创建对象的深拷贝，特别是当对象的属性是另一层对象时。

示例：

const person = {

  name: '快乐就是哈哈哈',

  age: 18,

  profession: 'coder',

  address: {

    city: 'Wonderland',

    postalCode: '12345'

  }

};



function deepCopy(obj) {

  const copy = {};

  Object.keys(obj).forEach(key => {

    if (typeof obj[key] === 'object' && obj[key] !== null) {

      copy[key] = deepCopy(obj[key]);

    } else {

      copy[key] = obj[key];

    }

  });

  return copy;

}



const copiedPerson = deepCopy(person);

console.log(copiedPerson);

是小姐姐，不是小哥哥~

这个功能放在之前是不可能实现的，因为考虑到用户的隐私，但是最近有一个新的api可以做到这一点。下面来进行一个简单的功能实现。

如何选择文件夹

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

</head>

<body>

  <button>打开文件夹</button>

  <script>

    var btn = document.querySelector('button');

    btn.onclick=function() {

        showDirectoryPicker()

    }

  </script>

</body>



</html>

我们调用showDirectoryPicker这个函数就可以实现一个选择文件夹的功能。

showDirectoryPicker()

• options 可选
  
  

  选项对象，包含以下属性：id通过指定 ID，浏览器能够记住不同 ID 所对应的目录。当使用相同的 ID 打开另一个目录选择器时，选择器会打开相同的目录。mode字符串，默认为 "read"，可对目录进行只读访问。设为 "readwrite" 可对目录进行读写访问。startIn一个 FileSystemHandle 对象或者代表某个众所周知的目录的字符串（如："desktop"、"documents"、"downloads"、"music"、"pictures"、"videos"）。用于指定选择器的起始目录。

返回值

一个 Promise 对象，会兑现一个 FileSystemDirectoryHandle (en-US) 对象。

异常

• AbortError
  
  

  当用户直接关闭了目录选择器或选择的目录是敏感目录时将会抛出 AbortError。

如何得到文件夹中的文件/子文件夹

首先对于上面所写的东西，我们进行try catch的优化

try {

  // 获得文件夹的句柄

  const handle = await showDirectoryPicker();

}

catch {

  //用户拒绝查看文件

  alert('访问失败')

}

之后我们来看一下这个headler打印出来是什么

句柄的简单解释

对于“句柄”，在下一直停留在一知半解的认识层面，近日在下学习Windows编程，决定趁此机会将句柄彻底搞清楚。查阅了一些网络上的资料，发现网络上的讲解大概可以分为两类：一种是以比喻、类比的方式说明，这种方法虽然形象易懂，但并没有从原理上、本质上加以揭示，让人仍然想问“为什么？”、“怎么实现？”。另一种是给出源代码，无可厚非，这当然是最本质的说明了，但这样一来，又显得不够直观，初学者理解起来有一定的难度。鉴于此，在下尽微末之能，结合自己的愚见，在两者之间折中，用图解的方式来将原理呈现出来，做到一目了然。

这里需要说明：

1.这里将句柄所能标识的所有东西（如窗口、文件、画笔等）统称为“对象”。

2.图中一个小横框表示一定大小的内存区域，并不代表一个字节，如标有0X00000AC6的横框表示4个字节。

3.图解的目的是为了直观易懂，所以不一定与源码完全对应，会有一定的简化。

让我们先看图，再解释。

其中，图1是程序运行到某时刻时的内存快照，图2是程序往后运行到另一时刻时的内存快照。红色部分标出了两次的变化。

简单解释：

Windows是一个以虚拟内存为基础的操作系统，很多时候，进程的代码和数据并不全部装入内存，进程的某一段装入内存后，还可能被换出到外存，当再次需要时，再装入内存。两次装入的地址绝大多数情况下是不一样的。也就是说，同一对象在内存中的地址会变化。（对于虚拟内存不是很了解的读者，可以参考有关操作系统方面的书籍）那么，程序怎么才能准确地访问到对象呢？为了解决这个问题，Windows引入了句柄。

系统为每个进程在内存中分配一定的区域，用来存放各个句柄，即一个个32位无符号整型值（32位操作系统中）。每个32位无符号整型值相当于一个指针，指向内存中的另一个区域（我们不妨称之为区域A）。而区域A中存放的正是对象在内存中的地址。当对象在内存中的位置发生变化时，区域A的值被更新，变为当前时刻对象在内存中的地址，而在这个过程中，区域A的位置以及对应句柄的值是不发生变化的。这种机制，用一种形象的说法可以表述为：有一个固定的地址（句柄），指向一个固定的位置（区域A），而区域A中的值可以动态地变化，它时刻记录着当前时刻对象在内存中的地址。这样，无论对象的位置在内存中如何变化，只要我们掌握了句柄的值，就可以找到区域A，进而找到该对象。而句柄的值在程序本次运行期间是绝对不变的，我们（即系统）当然可以掌握它。这就是以不变应万变，按图索骥，顺藤摸瓜。

**所以，我们可以这样理解Windows **句柄：

数值上，是一个32位无符号整型值（32位系统下）；逻辑上，相当于指针的指针；形象理解上，是Windows中各个对象的一个唯一的、固定不变的ID；作用上，Windows使用句柄来标识诸如窗口、位图、画笔等对象，并通过句柄找到这些对象。

下面，关于句柄，再交代一些关键性细节：

1.所谓“唯一”、“不变”是指在程序的一次运行中。如果本次运行完，关闭程序，再次启动程序运行，那么这次运行中，同一对象的句柄的值和上次运行时比较，一般是不一样的。

其实这理解起来也很自然，所谓“一把归一把，这把是这把，那把是那把，两者不相干”（“把”是形象的说法，就像打牌一样，这里指程序的一次运行）。

2.句柄是对象生成时系统指定的，属性是只读的，程序员不能修改句柄。

3.不同的系统中，句柄的大小（字节数）是不同的，可以使用sizeof()来计算句柄的大小。

4.通过句柄，程序员只能调用系统提供的服务（即API调用），不能像使用指针那样，做其它的事。

再回归正题。

处理句柄函数

async function processHandler(handle) {

  if (handle.kind==='file'){

    return handle

  }

    handle.children=[]

    const iter = await handle.entries();//获得文件夹中的所有内容

    //iter:异步迭代器

    for await (const info of iter){

      var subHandle = await processHandler(info[1]);

      handle.children.push(subHandle)

    }

    return handle

}

如何得到文件内容

const root = await processHandler(handle);

//   获得文件内容

 const file = await root.children[1].getFile();

 const reader = new FileReader();

 reader.onload=e=>{

   // 读取结果

   console.log(e.target.result)

 }

 reader.readAsText(file,'utf-8')

这里用到的就是一个很简单的文件读了。

下面是完整的代码

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

</head>

<body>

  <button>打开文件夹</button>

  <script>

    var btn = document.querySelector('button');

    btn.onclick=async function() {



      try {

         // 获得文件夹的句柄

         const handle = await showDirectoryPicker();

         const root = await processHandler(handle);

       //   获得文件内容

        const file = await root.children[1].getFile();

        const reader = new FileReader();

        reader.onload=e=>{

          // 读取结果

          console.log(e.target.result)

        }

        reader.readAsText(file,'utf-8')

       }

       catch {

         //用户拒绝查看文件

         alert('访问失败')

       }

    }

    async function processHandler(handle) {

      if (handle.kind==='file'){

        return handle

      }

        handle.children=[]

        const iter = await handle.entries();//获得文件夹中的所有内容

        //iter:异步迭代器

        for await (const info of iter){

          var subHandle = await processHandler(info[1]);

          handle.children.push(subHandle)

        }

        return handle

    }

  </script>

</body>



</html>

1. 分享目标：

2. 什么是微前端？

故事开始于三年前…

小明为公司重构了一版新的管理后台，采用了市面上最流行的SPA渲染模式，具体技术栈使用的是 react + react-router。

项目第一版很快就顺利上线了，但在后续的迭代中，遇到一个棘手的问题：产品经理希望快速复用之前项目的某些页面。这让小明犯了难，因为老项目是用“上古神器” jQuery 写的，完全重构成 react，成本非常高。这时后端老哥丢过来一句：“你们前端用 iframe 嵌进来就可以了吧？ ” 小明心里很清楚 iframe 有许多小毛病，但在当时，也确实没有比它更好的选择了。

上线后，随着时间的推移，用户产生了困惑：

1. 为什么这个页面的弹框不居中了？
2. 为什么这个页面的跳转记录无法保存？ ...

小明心里其实非常清楚，这一切都是 iframe 带来的弊端。

时间来到三年后的今天，小明听说微前端能够解决 iframe 的各种疑难杂症，于是展开了调研。

市面上对微前端的定义让人眼花缭乱，比如微前端是：

这里给出我对微前端最接地气的定义：

“类似于iframe的效果，但没有它带来的各种问题”——小明。

3. 主流技术方向分类

首先，“微前端”作为近几年国内前端界最火的技术之一，目前存在多个技术流派。我按照它们对 iframe 看法的不同，将主流微前端方案分为了三大派系：革新派、改良派、中间派。

3.1. 革新派 qiankun

以 qiankun 为主的革新派认为： iframe 问题很多，应避免使用它。 完全可以利用现有的前端技术自建一套应用隔离渲染方案。

3.1.1. 原理：

3.1.1.1. 基于 single-spa

将路由切换与子应用加载、卸载等生命周期结合起来是微前端的一项核心能力。这一步 qiankun 是基于 single-spa 实现的，不同的是它支持以 html 作为加载子应用的入口，不必像 single-spa 那样需要手动梳理资源链接，内部插件 import-html-entry 会自动分析 html 以获取 js 和 css。

3.1.1.2. 样式隔离

为了确保子应用之间样式互不影响，qiankun 内置了三种样式隔离模式：

1. 默认模式。

原理是加载下一个子应用时，将上一个子应用的 、等样式相关标签通通删除与替换，来实现样式隔离。缺点是仅支持单例模式（同一时间只能渲染单个子应用），且没法做到主子应用及多个子应用之间的样式隔离。

2. 严格模式。

可通过 strictStyleIsolation：true 开启。原理是利用 webComponent 的 shadowDOM 实现。但它的问题在于隔离效果太好了，在目前的前端生态中有点水土不服，这里举两个例子。

• 可能会影响 React 事件。比如这个issue 当 Shadow Dom 遇上 React 事件 ，大致原因是在 React 中事件是“合成事件”，在React 17 版本之前，所有用户事件都需要冒泡到 document 上，由 React 做统一分发与处理，如果冒泡的过程中碰到 shadowRoot 节点，就会将事件拦截在 shadowRoot 范围内，此时event.target 强制指向 shadowRoot，导致在 react 中事件无响应。React 17 之后事件监听位置由 document 改为了挂载 App 组件的 root 节点，就不存在此问题了。

• 弹框样式丢失。 原因是主流UI框架比如 antd 为了避免上层元素的样式影响，通常会把弹框相关的 DOM 通过 document.body.appendChild插入到顶层 body 的下边。此时子应用中 antd 的样式规则，由于开启了 shadowDom ，只对其下层的元素产生影响，自然就对全局 body 下的弹框不起作用了，造成了样式丢失的问题。

解决方案：调整 antd 入参，让其在当前位置渲染。

3. 实验模式。

可通过 experimentalStyleIsolation：true 开启。 原理类似于 vue 的 scope-css，给子应用的所有样式规则增加一个特殊的属性选择器，限定其影响范围，达到样式隔离的目的。但由于需要在运行时替换子应用中所有的样式规则，所以目前性能较差，处于实验阶段。

3.1.1.3. JS 沙箱

确保子应用之间的“全局变量”不会产生冲突。

1. 快照沙箱（ snapshotSandbox ）

• 激活子应用时，对着当前 window 对象照一张相（所有属性 copy 到一个新对象 windowSnapshot 中保存起来）。
• 离开子应用时，再对着 window 照一张相，对比离开时的 window 与激活时的 window （也就是 windowSnapshot ）之间的差异。
  • 记录变更。Diff 出在这期间更改了哪些属性，记录在 modifyPropsMap 对象中。
  • 恢复环境。依靠 windowSnapshot 恢复之前的 window 环境。
• 下次激活子应用时，从 modifyPropsMap 对象中恢复上一次的变更。

2. 单例的代理沙箱 （ LegacySanbox ）

与快照沙箱思路很相似，但它不用通过 Diff 前后 window 的方式去记录变更，而是通过 ES6的 Proxy 代理 window 属性的 set 操作来记录变更。由于不用反复遍历 window，所以性能要比快照沙箱好。

3. 支持多例的代理沙箱（ ProxySandbox ）

以上两种沙箱机制，都只支持单例模式（同一页面只支持渲染单个子应用）。

原因是：它们都直接操作的是全局唯一的 window。此时机智的你肯定想到了，假如为每个子应用都分配一个独立的“虚拟window”，当子应用操作 window 时，其实是在各自的“虚拟 window”上操作，不就可以实现多实例共存了？事实上，qiankun 确实也是这样做的。

既然是“代理”沙箱，那“代理”在这的作用是什么呢？

主要是为了实现对全局对象属性 get、set 的两级查找，优先使用fakeWindow，特殊情况(set命中白名单或者get到原生属性)才会改变全局真实window。

如此，qiankun 就对子应用中全局变量的 get 、 set 都实现了管控与隔离。

3.1.2. 优势：

3.1.2.1. 具有先发优势

2019年开源，是国内最早流行起来的微前端框架，在蚂蚁内外都有丰富的应用，后期维护性是可预测的。

3.1.2.2. 开箱即用

虽然是基于国外的 single-spa 二次封装，但提供了更加开箱即用的 API，比如支持直接以 HTML 地址作为加载子应用的入口。

3.1.2.3. 对 umi 用户更加友好

有现成的插件 @umijs/plugin-qiankun 帮助降低子应用接入成本。

3.1.3. 劣势：

3.1.3.1. vite 支持性差

由上可知，代理沙箱实现的关键是需要将子应用的 window “替换”为 fakeWindow，在这一步 qiankun 是通过函数 window 同名参数 + with 作用域绑定的方式，更改子应用 window 指向为 fakeWindow，最终使用 eval(...) 解析运行子应用的代码。

const jsCode = `

(function(window, self, globalThis){

    with(this){

      // your code

      window.a = 1;

      b = 2

      ...

	}

}).bind(window.proxy)(window.proxy, window.proxy, window.proxy);

` 

eval(jsCode)

问题就出在这个 eval 上， vite 的构建产物如果不做特殊降级，默认打包出的就是 ESModule 语法的代码，使用 eval 解析运行会报下图这个错误。

报错的大意是， import 语法的代码必须放在 中执行。

官方目前推荐的解决方法是关闭沙箱... 但其实还有另一种比较取巧的方案：vite 生态里有一款专门兼容此问题的vite-plugin-qiankun 插件，它的原理是： eval 虽然没办法执行静态 import 语法，但它可以执行动态 import(...) 语法。

所以这款插件的解决方案就是替换子应用代码中的静态 import 为动态 import()，以绕过上述限制。

3.1.3.2. 子应用接入成本较高，详细步骤参考子应用接入文档

umi 用户可忽略这点，尤其是 @umi/max 用户，相比 webpack 接入成本要低很多。

3.1.3.3. JS 沙箱存在性能问题，且并不完善。

大致原因是 with + proxy 带来的性能损耗，详见 JS沙箱的困境 。当然 qiankun 官方也在针对性的进行优化，进展在这篇《改了 3 个字符，10倍的沙箱性能提升？！！》文章中可见一斑 。

3.2. 改良派 wujie

3.2.1. 原理：

wujie 是腾讯出品的一款微前端框架。作为改良派的代表，它认为： iframe 虽然问题很多，但仅把它作为一个 js 沙箱去用，表现还是很稳定的，毕竟是浏览器原生实现的，比自己实现 js 沙箱靠谱多了。至于 iframe 的弊端，可以针对性的去优化：

• DOM 渲染无法突破 iframe 边界？(弹框不居中问题)

那 DOM 就不放 iframe 里渲染了，而是单独提取到一个 webComponent 里渲染，顺便用 shadowDOM 解决样式隔离的问题。

简单说，无界的方案就是：JS 放 iframe 里运行，DOM 放 webComponent 渲染。

那么问题来了： 用 JS 操作 DOM 时，两者如何联系起来呢？毕竟 JS 默认操作的总是全局的 DOM。无界在此处用了一种比较 hack 的方式：代理子应用中所有的 DOM 操作，比如将 document 下的 getElementById、querySelector、querySelectorAll、head、body 等查询类 api 全部代理到 webComponent。

下图是子应用真实运行时的例子：

至于多实例模式，就更容易理解了。给每个子应用都分配一套 iframe + webComponent 的组合，就可以实现相互之间的隔离了！

• 刷新页面会导致子应用路由状态丢失？

通过重写 iframe 实例的history.pushState 和 history.replaceState，将子应用的 path 记录到主应用地址栏的 query 参数上，当刷新浏览器初始化 iframe 时，从地址栏读到子应用的 path 并使用 iframe 的 history.replaceState 进行同步。

简单理解就是：将子应用路径记录在地址栏参数中。

3.2.2. 优势：

3.2.2.1. 相比 qiankun 接入成本更低。

• 父应用：
  • 与 iframe 的接入方式很类似，只需引入一个 React 组件渲染子应用即可。

• 子应用理论上不需要做任何改造

3.2.2.2. vite 兼容性好

直接将完整的 ESM 标签块  插入 iframe 中，避免了 qiankun 使用 eval 执行 ESM 代码导致的报错问题。

3.2.2.3. iframe 沙箱隔离性好

3.2.3. 劣势：

3.2.3.1. 坑比较多

• 明坑： 用于 JS 沙箱的 iframe 的 src 必须指向一个同域地址导致的问题。

  具体问题描述见下图：

此 [issue]() 至今无法在框架层面得到解决，属于 iframe 的原生限制。

手动的解决方案：

• 主应用提供一个路径比如说 https://host/empty ，这个路径不需要返回任何内容，子应用设置 attr 为 {src:'https://host/empty'}，这样 iframe 的 src 就是 https://host/empty。
• 在主应用 template 的 head 插入这样的代码可以避免主应用代码污染。
• 暗坑： 复杂的 iframe 到 webComponent 的代理机制，导致市面上大部分富文本编辑器都无法在无界中完好运行。所以有富文本的项目，尽量别用无界，除非你对富文本库的源码了如指掌。issues 在这里。

3.2.3.2. 长期维护性一般。

3.2.3.3. 内存开销较大

用于 js 沙箱的 iframe 是隐藏在主应用的 body 下面的，相当于是常驻内存，这可能会带来额外的内存开销。

3.3. 中间派 micro-app

3.3.1. 原理：

京东的大前端团队出品。

样式隔离方案与 qiankun 的实验方案类似，也是在运行时给子应用中所有的样式规则增加一个特殊标识来限定 css 作用范围。

子应用路由同步方案与 wujie 类似，也是通过劫持路由跳转方法，同步记录到 url 的 query 中，刷新时读取并恢复。

组件化的使用方式与 wujie 方案类似，这也是 micro-app 主打的宣传点。

最有意思的是它的沙箱方案，居然内置了两种沙箱：

1. 类 qiankun 的 with 代理沙箱，据说相比 qiankun 性能高点，但目前微前端框架界并没有一个权威的基准性能测试依据，所以并无有效依据支撑。
2. 类 wujie 的 iframe 沙箱，用于兼容 vite 场景。

开发者可以根据自身的实际情况自由选择。

整体感觉 micro-app 是一种偏“现实主义”的框架，它的特点就是取各家所长，最终成为了功能最丰富的微前端框架。

3.3.2. 优势：

3.3.2.1. 支持的功能最丰富。

3.3.2.2. 接入成本低。

3.3.2.3. 文档完善。

micro-zoe.github.io/micro-app/d…

3.3.3. 劣势：

3.3.3.1. 功能丰富导致配置项与 api 太多。

3.3.3.2. 静态资源补全问题。

静态资源补全是基于父应用的，而非子应用这需要开发者自己手动解决。

4. 选型建议

统计时间2023.12.3	npm周下载量	star数	issue数	最近更新时间	接入成本	沙箱支持vite
qiankun	22k	15k	362/1551	12天前	高	❌
wujie	1.3k	3.4k	280/271	24天前	低	✅
micro-app	1.1k	4.9k	57/748	1个月前	中	✅

1. 刚性建议。

• vite 项目且对 js 沙箱有刚需，选 wujie 或者 micro-app。
• 项目存在复杂的交互场景，比如有用到富文本编辑器库，选 wujie 前请做好充分的测试。
• 如果你的团队对主、子应用的开发完全受控，即使有隔离性问题也可以通过治理来解决，那么可以试试更轻量的 single-SPA 方案。
• 如果特别重视稳定性，那无疑是 iframe 最佳... 因为 iframe 存在的问题都是摆在明面的，市面上现有的微前端框架多多少少都有一些隐性问题。

2. 综合推荐。

主要从接入成本、功能稳定性、长期维护性三方面来衡量：

• 接入成本： wujie > microApp > qiankun （由低到高）
• 功能稳定性：qiankun > microApp > wujie
• 长期维护性：qiankun > microApp > wujie

看你的团队最看重哪一点，针对性去选择就好了，没有十全十美微前端框架，只有适合自己的。

最后

以上内容，确实会有我强烈的个人理解与观点，这也是我写文章一贯的风格。我并不喜欢那种客观且枯燥无味的文章，读完之后感觉像流水账，给不了读者任何的指导。我认为文章就是要有观点输出，技术文章也不例外，如果非常看重准确无误的表达，可以直接去看说明文档or源码，那应该是最权威的知识。如有错误或者误解，可以评论区或者私信指出，我积极改正。

作者：郑鱼咚
来源：juejin.cn/post/7309477710523269174

❝

工欲善其事必先利其器，使用过内网开发的小伙伴都知道，CV大法在内网基本就废了，查资料也是非常的不便。对于一名程序员来说，如果把搜索引擎和CV键给他ban了，遇到问题后那基本是寸步难行。今天给大家介绍几种帮助内网开发提效的方法，希望能够帮助到大家。

一、文档站点内网部署

可以把项目中所用技术和框架的文档部署到公司内网中。

以elementPlus为例：

1、访问gh-pages分支https://github.com/element-plus/element-plus/tree/gh-pages，下载文档站源码。

2、将文档站部署到内网服务器（以nginx为例）。

    server {

        listen       9800;

        server_name  localhost;



        location / {

            root   html/element-plus-gh-pages;

            index  index.html index.htm;

            try_files $uri $uri/ /element-plus-gh-pages/index.html;

        }



        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   html;

        }

    }

部署后的访问速度也是非常快的

使用这种方式，随着部署的站点增多，后续框架、文档更新的时候，维护起来相对是比较麻烦的。且只能查看文档，遇到问题需要求助度娘还是不太方便。

下面介绍两种物理外挂，可以直接访问外网。

二、USB跨屏穿越器数据线

个人感觉此方案的体验是最好的，缺点是需要两台电脑，并且需要花钱买一根线，价格在80-200之间。

购买

某宝、某鱼都有销售，我是在某宝85块买的。

使用

连接两台电脑的USB端口即可，会自动安装驱动，那根线实际上就相当于是一个文件中转器，可以实现剪切板、文件的互传。使用体验就跟一台电脑连接了两台显示器一样。如下图所示：

三、手机投屏

本文重点介绍此方案，因为可以白嫖且不需要第二台电脑。一部安卓手机+数据线即可，缺点是文件传输不太方便。它就是一个开源投屏项目scrcpy。可以看到，此项目在github上拥有高达102k的star数量。

✨亮点

• 亮度 （原生，仅显示设备屏幕）


• 表演 （30~60fps）


• 质量 （1920×1080或以上）


• 低延迟 （70~100ms）


• 启动时间短 （显示第一张图像约1秒）


• 非侵入性 （设备上没有安装任何东西）


• 不需要 ROOT


• 有线无线都可连接


• 可以随便调整界面和码率


• 画面随意裁剪，自带录屏（手游直播利器）


• 支持多设备同时投屏


• 利用电脑的键盘和鼠标可以控制手机


• 把 APK 文件拖拽到电脑窗口即可安装应用到手机，把普通文件拖拽到窗口即可复制到手机


• 手机电脑共享剪贴板


• 自动检测USB连接的设备


• 可直接添加设备的局域网IP，达到无线控制的效果


• 将自动保存连接过的IP地址，下次输入时，自动提醒


• 支持设备别名


• 支持中英两种语言


• Tray menu


• 等等等...

安装

根据不同系统直接去release页面下载对应版本即可：github.com/Genymobile/…

使用

下载解压完，进入软件目录，点击下图按钮打开命令行界面，输入启动命令即可。

命令行输入scrcpy，按回车， 猿神，起洞！

启动之后，即可使用鼠标操作手机，非常的丝滑

1、手机复制文本到电脑

2、电脑复制文本到手机

可以看到，使用投屏的方式，也可以实现CV大法。并且可以使用手机端的外网搜索资料、解决问题等。以下是该项目的快捷键，熟练使用，即可达到人机合一的地步。

快捷键

使用小技巧

经过笔者几天的使用，总结出几个小技巧。

1、电脑键盘控制手机进行中文输入，必须使用正确的输入法组合。

手机端：讯飞输入法(搜狗输入法不支持)

电脑端：ENG(使用英文键盘)

2、手机熄屏状态下投屏。 在scrcpy命令后加上熄屏参数即可：scrcpy --turn-screen-off

这样就可以在手机熄屏的状态下，仍可以被电脑操作，达到节省电量和减轻发热的目的。

诸如此类的命令参数还有很多，执行scrcpy --help就可查看详细的帮助文档。

衍生项目

因为开源的特性，scrcpy也衍生了一些相关项目，列举其中一些：

• QtScrcpy 使用qt重新实现的桌面端，并加强了对游戏的支持。


• scrcpy-gui 为scrcpy的命令行提供了gui界面。


• guiscrcpy 另一个scrcpy的gui界面。


• scrcpy-docker docker版本的scrcpy。


• scrcpy-go go语言版本的scrcpy，增强对游戏的支持。

总结

第二第三种方法虽然建立了内网开发电脑和外网设备的联系，但是是不会被公司的安全系统检测到一机双网的，因为其本质就类似于设计模式中的发布订阅模式，用数据线充当了中间人，两台设备之间方便传输数据了而已，不会涉及到联网。

内网开发的痛点，无非就是复制粘贴、文件传输不便，只要打通这个链路，就能解决此问题。以上三个方法，笔者在实际工作中都用到了，确实极大的提高了工作效率。如果你也在饱受内网开发的折磨，不妨试试这几个方法。

背景

最近在开发H5，ui稿给的border：1px solid,因为ui稿上的宽度是750px，我们运行的页面宽度是375px，所以我们需要把所以尺寸/2。所以我们可能会想写border：0.5px solid。但是实际上，我们看页面渲染，仍然是渲染1px而不是0.5

示例代码

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <style>

      * {

        margin: 0;

        padding: 0;

        box-sizing: border-box;

      }



      body {

        font-family: Arial, sans-serif;

      }



      .flex {

        display: flex;

      }

      .item {

        margin-right: 10px;

        padding: 10px;

        font-size: 13px;

        line-height: 1;

        background-color: rgba(242, 243, 245,1);

      }

      .active {

        color: rgba(250, 100, 0, 1);

        font-size: 14px;

        border: 0.5px solid ;

      }

    </style>

  </head>

  <body>

    <div class="flex">

      <!-- <div class="item active">

        active

      </div> -->

      <div class="item">

        item1

      </div>

      <div class="item">

        item2

      </div>

      <div class="item">

        item3

      </div>

    </div>

  </body>

</html>

在没active的情况下

他们的内容都是占13px

在有active的情况下

active占了14px这个是没问题的，因为它font-size是14px嘛，但是我们是设置了border的宽度是0.5px，但展现的却是1px。

再来看看item

它内容占了16px，它受到相邻元素影响是14px+2px的上下边框

为啥border是1px呢

在 CSS 中，边框可以设置为 0.5px，但在某些情况下，尤其是低分辨率的屏幕上，浏览器可能会将其渲染为 1px 或根本不显示。这是因为某些浏览器和显示设备不支持小于 1px 的边框宽度或不能准确渲染出这样的细小边框。

浏览器渲染机制

• 不同浏览器对于小数像素的处理方式不同。一些浏览器可能会将 0.5px 边框四舍五入为 1px，以确保在所有设备上的一致性。

设备像素比

• 在高 DPI（如 Retina 显示器）设备上，0.5px 边框可能看起来更清晰，因为这些设备可以渲染更细的边框。


• 在低 DPI 设备上，0.5px 边框可能会被放大或者根本不会被显示。

解决办法

方法一：使用伪类和定位

.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

}

.active::after {

  content: "";

  pointer-events: none;

  display: block;

  position: absolute;

  left: 0;

  top: 0;

  transform-origin: 0 0;

  border: 1px #ff892e solid;

  box-sizing: border-box;

  width: 100%;

  height: 100%;

}

另外的item的内容高度也是14px了符合要求

方法二：使用阴影，使用F12看的时候感觉还是有些问题

.active2 {

  margin-left: 10px;

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

  box-shadow: 0 0 0 0.5px #ff892e;

}

方法三：使用svg，但这种自己设置了宽度。

<div class="active">

  <svg width="100%" height="100%" viewBox="0 0 100 100" preserveAspectRatio="none">

    <rect x="0" y="0" width="100" height="100" fill="none" stroke="#ff892e" stroke-width="0.5"></rect>

  </svg>

  active

</div>

方案四：使用svg加定位，也比较麻烦，而且有其他的问题

<div class="active">

    <svg viewBox="0 0 100 100" preserveAspectRatio="none">

        <rect x="0" y="0" width="100" height="100" fill="none" stroke="#ff892e" stroke-width="0.5"></rect>

    </svg>

    <div class="content">active</div>

</div>

.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

  display: inline-block; 

}

.active svg {

  position: absolute;

  top: 0;

  left: 0;

  width: 100%;

  height: 100%;

  pointer-events: none; 

  box-sizing: border-box;

}

.active .content {

  position: relative;

  z-index: 1; 

}

方法五：使用一个父元素 比较麻烦

<div class="border-container">

  <div class="active">active</div>

</div>



.border-container {

  display: inline-block;

  padding: 0.5px; 

  background-color: #ff892e; 

}



.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  background-color: white; 

}

最后

在公司里，我们使用的都是方案一，这样active和item它们的内容高度都是14px了。然后我们再给他们的父盒子加上 align-items: center。这样active的高度是14px，其他都是13px了。但是active的高度会比其他item的盒子高1px，具体看个人需求是否添加吧。

1、背景

前两天老板找到我说有一个需求，要求使用英雄联盟的人物动画制作一个加载中的组件，类似于下面这样：

我定眼一看：这个可以实现，但是需要UI妹子给切图。

老板：UI？ 咱们啥时候招的UI !

我：老板，那不中呀，不切图弄不成呀。

老板：下个月绩效给你A。

我：那中，管管管。

2、调研

发动我聪明的秃头，实现这个需求有以下几种方案：

• 切动画帧，没有UI不中❎。


• 去lol客户端看看能不能搞到什么美术素材，3D模型啥的，可能行❓


• 问下 gpt4o，有没有哪个老表收集的有lol英雄的美术素材，如果有那就更得劲了✅。

经过我一番搜索，发现了这个网站：model-viewer，收集了很多英雄联盟的人物模型，模型里面还有各种动画，还给下载。老表，这个需求稳了50%了！

接下来有几种选择：

• 将模型动画转成动画帧，搞成雪碧图，较为麻烦，且动画不支持切换。


• 直接加载模型，将模型放在进度条上，较为简单，支持切换不同动画，而且可以自由过渡。就是模型文件有点大，初始化加载可能耗时较长。但是后续缓存一下就好了。

聪明的我肯定先选第二个方案呀，你糊弄我啊，我糊弄你。

3、实现

web中加载模型可以使用谷歌基于threejs封装的 model-viewer, 使用现代的 web component 技术。简单易用。

先初始化一个vue工程

 npm create vue@latest

然后将里面的初始化的组件和app.vue里面的内容都删除。

安装model-viewer依赖：

npm i three // 前置依赖

npm i @google/model-viewer

修改vite.config.js，将model-viewer视为自定义元素，不进行编译

import { fileURLToPath, URL } from 'node:url'

​

import { defineConfig } from 'vite'

import vue from '@vitejs/plugin-vue'

​

// https://vitejs.dev/config/

export default defineConfig({

  plugins: [

    vue({

      template: {

        // 添加以下内容

        compilerOptions: {

          isCustomElement: (tag) => ['model-viewer'].includes(tag)

        }

      }

    })

  ],

  resolve: {

    alias: {

      '@': fileURLToPath(new URL('./src', import.meta.url))

    }

  },

  assetsInclude: ['./src/assets/heros/*.glb']

})

​

新建 src/components/LolProgress.vue

<template>

  <div class="progress-container">

    <model-viewer

      :src="hero.src"

      disable-zoom

      shadow-intensity="1"

      :camera-orbit="hero.cameraOrbit"

      class="model-viewer"

      :style="heroPosition"

      :animation-name="animationName"

      :camera-target="hero.cameraTarget"

      autoplay

      ref="modelViewer"

    ></model-viewer>

    <div

      class="progress-bar"

      :style="{ height: strokeWidth + 'px', borderRadius: strokeWidth / 2 + 'px' }"

    >

      <div class="progress-percent" :style="currentPercentStyle"></div>

    </div>

  </div>

</template>

​

<script setup lang="ts">

import { computed, onMounted, ref, watch, type PropType } from 'vue'

/** 类型 */

interface Hero {

  src: string

  cameraOrbit: string

  progressAnimation: string

  finishAnimation: string

  finishAnimationIn: string

  cameraTarget: string

  finishDelay: number

}

type HeroName = 'yasuo' | 'yi'

​

type Heros = {

  [key in HeroName]: Hero

}

const props = defineProps({

  hero: {

    type: String as PropType<HeroName>,

    default: 'yasuo'

  },

  percentage: {

    type: Number,

    default: 100

  },

  strokeWidth: {

    type: Number,

    default: 10

  },

  heroSize: {

    type: Number,

    default: 150

  }

})

​

const modelViewer = ref(null)

​

const heros: Heros = {

  yasuo: {

    src: '/src/components/yasuo.glb',

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run2',

    finishAnimationIn: 'yasuo_skin02_dance_in',

    finishAnimation: 'yasuo_skin02_dance_loop',

    cameraTarget: 'auto auto 0m',

    finishDelay: 2000

  },

  yi: {

    src: '/src/components/yi.glb',

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run',

    finishAnimationIn: 'Dance',

    finishAnimation: 'Dance',

    cameraTarget: 'auto auto 0m',

    finishDelay: 500

  }

}

​

const heroPosition = computed(() => {

  const percentage = props.percentage > 100 ? 100 : props.percentage

  return {

    left: `calc(${percentage + '%'} - ${props.heroSize / 2}px)`,

    bottom: -props.heroSize / 10 + 'px',

    height: props.heroSize + 'px',

    width: props.heroSize + 'px'

  }

})

​

const currentPercentStyle = computed(() => {

  const percentage = props.percentage > 100 ? 100 : props.percentage

  return { borderRadius: `calc(${props.strokeWidth / 2}px - 1px)`, width: percentage + '%' }

})

​

const hero = computed(() => {

  return heros[props.hero]

})

​

const animationName = ref('')

​

watch(

  () => props.percentage,

  (percentage) => {

    if (percentage < 100) {

      animationName.value = hero.value.progressAnimation

    } else if (percentage === 100) {

      animationName.value = hero.value.finishAnimationIn

      setTimeout(() => {

        animationName.value = hero.value.finishAnimation

      }, hero.value.finishDelay)

    }

  }

)

onMounted(() => {

  setTimeout(() => {

    console.log(modelViewer.value.availableAnimations)

  }, 2000)

})

</script>

<style scoped>

.progress-container {

  position: relative;

  width: 100%;

}

.model-viewer {

  position: relative;

  background: transparent;

}

.progress-bar {

  border: 1px solid #fff;

  background-color: #666;

  width: 100%;

}

.progress-percent {

  background-color: aqua;

  height: 100%;

  transition: width 100ms ease;

}

</style>

组件非常简单，核心逻辑如下：

• 根据传入的英雄名称加载模型


• 指定每个英雄的加载中的动画，


• 加载100%,切换完成动作进入动画和完成动画即可。


• 额外的细节处理。
  
  

  最后修改 app.vue:

  
  

  <script setup lang="ts">
  
  import { ref } from 'vue'
  
  import LolProgress from './components/LolProgress.vue'
  
  const percentage = ref(0)
  
  setInterval(() => {
  
    percentage.value = percentage.value + 1
  
  }, 100)
  
  </script>
  
  ​
  
  <template>
  
    <main>
  
      <LolProgress
  
        :style="{ width: '200px' }"
  
        :percentage="percentage"
  
        :heroSize="200"
  
        hero="yasuo"
  
      />
  
    </main>
  
  </template>
  
  ​
  
  <style scoped></style>
  
  ​
  
  

  
  

这不就完成了吗，先拿给老板看看。

老板：换个女枪的看看。

我：好嘞。

老板：弄类不赖啊小伙，换个俄洛伊的看看。

4、总结

通过本次需求，了解到了 model-viewer组件。

老板招个UI妹子吧。

在线体验：github-pages

前言

做了7年前端我一直不知道瀑布流是什么（怪设计师不争气啊，哈哈哈），我一直以为就是个普通列表，几行css解决的那种。

当然瀑布流确实有css解决方案，但是这个方案对于分页列表来说完全不能用，第二页内容一出来位置都变了。

我看了一下掘金的一些文章，好长啊，觉得还是自己想一下怎么写吧。就自己实现了一遍。希望思路给大家一点帮助。

分析瀑布流

以小红书的瀑布流为例，相同宽度不同高度的卡片堆叠在一起形成瀑布流。

这里有两个难点：

• 卡片高度如何确定？


• 堆叠布局如何实现？

卡片的高度 = padding + imageHeight + textHeight....

不固定的内容包括：图片高度、标题行数

也就是说当我们解决了图片和标题的高度问题，那么瀑布流的第一个问题就解决了。（感觉已经写好代码了一样）

堆叠问题——因为css没有这样的布局方式，所以肯定得用js实现。最简单的解决方案就是对每一个盒子进行绝对定位。

这个问题就转换成计算现有盒子的定位问题。

从问题到代码

第一个问题——图片高度

无论是企业业务场景还是个人开发，通过后端返回图片的width、height都是合理且轻松的。

前端去获取图片信息，无疑让最重要的用户体验变得糟糕。前端获取图片信息并不困难，但是完全没有必要。

所以我直接考虑后端返回图片信息的情况。

const realImageHeight = imageWidth / imageHeight * cardContentWidth;  

图片高度轻松解决，无平台差异

第二个问题——文字高度

从小红书可以看出，标题有些两行有些一行，也有些三行。

如果你固定一行，这个问题完全可以跳过。

• 方案一：我们可以用字数和宽度来计算可能得行数
  
  优势：速度快，多平台复用
  
  劣势：不准确（标题包括英文中文）


• 方案二：我们可以先渲染出来再获取行数
  
  优势：准确
  
  劣势：相对而言慢，不同平台方法不同

准确是最重要的！选择方案二

其实方案二也有两种方案，一种是用canvas模拟，这样可以最大限度摆脱平台（h5、小程序）的限制，

然而我试验后，canvas还没找到准确的计算的方法（待后续更新）

第二种就是用div渲染一遍，获取行数或者高度。

创建一个带有指定样式的 div 元素

function createDiv(style: string): HTMLDivElement {  

    const div = document.createElement('div');  

    div.style.cssText = style;  

    document.body.appendChild(div);  

    return div;  

}  

计算文本数组在指定字体大小和容器宽度下的行数

/**  

* 计算文本数组在指定字体大小和容器宽度下的行数  

* @param texts - 要渲染的文本数组  

* @param fontSize - 字体大小（以像素为单位）  

* @param lineHeight - 字体高度（以像素为单位）  

* @param containerWidth - 容器宽度（以像素为单位）  

* @param maxLine - 最大行数（以像素为单位）  

* @returns 每个文本实际渲染时的行数数组  

*/  

export function calculateTextLines(  

    texts: string[],  

    fontSize: number,  

    lineHeight: number,  

    containerWidth: number,  

    maxLine?: number  

): number[] {  

// 创建一个带有指定样式的 div 元素  

    const div = createDiv(`font-size: ${fontSize}px; line-height: ${lineHeight}px; width: ${containerWidth}px; white-space: pre-wrap;`);  

    const results: number[] = [];  

    texts.forEach((text) => {  

        div.textContent = text;  

        // 获取 div 的高度，并根据字体大小计算行数  

        const divHeight = div.offsetHeight;  

        const lines = Math.ceil(divHeight / lineHeight);  

        maxLine && lines > maxLine ? results.push(maxLine) : results.push(lines);  

    });  

  

    // 清理 div  

    removeElement(div);  



    return results;  

}  

这个问题小程序如何解决放在文末

第三个问题——每个卡片的定位问题

解决了上面的问题，就解决了盒子高度的问题，这个问题完全就是相同宽度不同高度盒子的堆放问题了

问题的完整描述是这样的：

写一个ts函数实现将一堆小盒子，按一定规则顺序推入大盒子里

函数输入：小盒子高度列表

小盒子：不同小盒子高度不一致，宽度为stackWidth，彼此间隔gap

大盒子：高度无限制，宽度为width

堆放规则：优先放置高度低的位置，高度相同时优先放在左侧

返回结果：不同盒子的高度和位置信息

如果你有了这么清晰的描述，接下去的工作你只需要交给gpt来写你的函数

// 返回的盒子信息  

export interface Box {  

    x: number;  

    y: number;  

    height: number;  

}  

// 盒子堆叠的方法类  

export class BoxPacker {  

    // 返回的小盒子信息列表  

    private boxes: Box[] = [];  

    // 大盒子宽度  

    private width: number;  

    // 小盒子宽度  

    private stackWidth: number;  

    // 小盒子间隔  

    private gap: number;  



    constructor(width: number, stackWidth: number, gap: number) {  

    this.width = width;  

    this.stackWidth = stackWidth;  

    this.gap = gap;  

    this.boxes = [];  

}  

// 添加单个盒子  

public addBox(height: number): Box[] {  

    return this.addBoxes([height]);  

}  

// 添加多个盒子（一般用这个方法）  

public addBoxes(heights: number[], isReset?: boolean): Box[] {  

    isReset && (this.boxes = [])  

    console.log('this.boxes—————— ', JSON.stringify(this.boxes) )  



    for (const height of heights) {  

        const position = this.findBestPosition();  

        const newBox: Box = { x: position.x, y: position.y, height };  

        this.boxes.push(newBox);  

    }  

    return this.boxes;  

}  

// 查找定位函数  

private findBestPosition(): { x: number; y: number } {  

    let bestX = 0;  

    let bestY = Number.MAX_VALUE;  



    for (let x = 0; x <= this.width - this.stackWidth; x += this.stackWidth + this.gap) {  

        const currentY = this.getMaxHeightInColumn(x, this.stackWidth);  

        if (currentY < bestY || (currentY === bestY && x < bestX)) {  

            bestX = x;  

            bestY = currentY;  

        }  

    }  



    return { x: bestX, y: bestY };  

}  

  

private getMaxHeightInColumn(startX: number, width: number): number {  

    return this.boxes  

        .filter(box => box.x >= startX && box.x < startX + width)  

        .reduce((maxHeight, box) => Math.max(maxHeight, box.y + box.height + this.gap), 0);  

}  

}  

  

这样我们就实现了根据高度获取定位的功能了

来实现一波

核心的代码就是获取每个盒子的定位、宽高信息

// 实例  

const boxPacker = useMemo(() => {  

    return new BoxPacker(width, stackWidth, gap)  

}, []);  

  

const getCurrentPosition = (currentData: DataItem[], reset?: boolean) => {  

    // 获取标题文本行数列表  

    const textLines = calculateTextLines(currentData.map(item => item.title),card.fontSize,card.lineHeight, cardContentWidth)  

    // 获取图片高度列表  

    const imageHeight = currentData.map(item => (item.imageHeight / item.imageWidth * cardContentWidth))  

    // 获取小盒子高度列表  

    const cardHeights = imageHeight.map((h, index) => (  

    h + textLines[index] * card.lineHeight + card.padding * 2 + (card?.otherHeight || 0)  

    )  

    );  

    // 获取盒子定位信息  

    const boxes = boxPacker.addBoxes(  

        cardHeights,  

        reset  

    )  

    // 返回盒子列表信息  

    return boxes.map((box, index) => ({  

        ...box,  

        title: currentData[index]?.title,  

        url: currentData[index]?.url,  

        imageHeight: imageHeight[index],  

    }))  

}  

set获取到的盒子信息

const [boxPositions, setBoxPositions] = useState<(Box & Pick<DataItem, 'url' | 'title' | 'imageHeight'>)[]>([]);  

useEffect(() => {  

    // 首次和刷新  

    if (page === 1) {  

        setBoxPositions(getCurrentPosition(data, true))  

    } else {  

    // 加载更多  

        setBoxPositions(getCurrentPosition(data.slice((page - 1) * pageSize, page * pageSize)))  

    }  

}, [])  

效果如下

小程序获取文本高度

从上面的分析可以看出来只有文本高度实现是不同的，如果canvas方案实验成功，说不定还能做到大一统。

目前没成功大家就先看看我的目前方案：先实际渲染文字然后读取信息，然后获取实际高度

import React, {useEffect, useMemo, useState} from 'react'  

import { View } from '@tarojs/components'  

import Taro from "@tarojs/taro";  

import './index.less'  

import {BoxPacker} from "./flow";  

  

const data = [  

    'vwyi这是一个标题，这是一个标题，这是一个标题，这是一个标题',  

    '这是一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,这是一个标题',  

    '这是一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,这题',  

    '这是一个标题,这是一个标题,这是一',  

    '这是一个标题,这是一个标题,这是一',  

];  

  

function Index() {  

const boxPacker = useMemo(() => new BoxPacker(320, 100, 5), []);  

  

const [boxPositions, setBoxPositions] = useState<any[]>([])  

function getTextHeights() {  

return new Promise((resolve, reject) => {  

    Taro.createSelectorQuery()  

        .selectAll('#textContainer .text-item')  

        .boundingClientRect()  

        .exec(res => {  

            if (res && res[0]) {  

                const heights = res[0].map(item => item.height);  

                resolve(heights);  

            } else {  

                reject('No buttons found');  

            }  

        });  

    });  

}  

useEffect(() => {  

    getTextHeights().then(h => {  

        setBoxPositions(boxPacker.addBoxes(h))  

    })  

}, [])  

return (  

<View className="flow-container">  

<View id="textContainer">  

{  

data.map((item, index) => (<View key={index} className="text-item">{item}</View>))  

}  

</View>  

<View className="text-box-container">  

{boxPositions.map((position, index) => (  

<View  

key={index}  

className="text-box"  

style={{  

left: `${position.x}px`,  

top: `${position.y}px`,  

height: `${position.height}px`,  

width: '100px', // 假设盒子的宽度固定为100px  

}}  

>  

{`${data[index]}`}  

</View>  

))}  

  

</View>  

  

</View>  

)  

}  

  

export default Index  

  

项目react源码地址

面试官：看你简历上做过图片或文件批量下载，那么假如我一次性下载几十个，如何去控制并发请求的？

让我想想，额~， 选中ID，循环请求？，八嘎！肯定不是那么沙雕的做法，这样做服务器直接崩溃啦！突然灵光一现，请求池！！！

我：利用Promise模拟任务队列，从而实现请求池效果。

面试官：大佬！

废话不多说，正文开始：

众所周知，浏览器发起的请求最大并发数量一般都是6~8个，这是因为浏览器会限制同一域名下的并发请求数量，以避免对服务器造成过大的压力。

首先让我们来模拟大量请求的场景

const ids = new Array(100).fill('')



console.time()

for (let i = 0; i < ids.length; i++) {

  console.log(i)

}

console.timeEnd()

一次性并发上百个请求，要是配置低一点，又或者带宽不够的服务器，直接宕机都有可能，所以我们前端这边是需要控制的并发数量去为服务器排忧解难。

什么是队列？

先进先出就是队列，push一个的同时就会有一个被shift。我们看下面的动图可能就会更加的理解：

我们接下来的操作就是要模拟上图的队列行为。

定义请求池主函数函数

export const handQueue = (  

  reqs // 请求数量

) => {}

接受一个参数reqs，它是一个数组，包含需要发送的请求。函数的主要目的是对这些请求进行队列管理，确保并发请求的数量不会超过设定的上限。

定义dequeue函数

const dequeue = () => {  

  while (current < concurrency && queue.length) {  

    current++;  

    const requestPromiseFactory = queue.shift() // 出列  

    requestPromiseFactory()  

      .then(() => { // 成功的请求逻辑  

      })  

      .catch(error => { // 失败  

        console.log(error)  

      })  

      .finally(() => {  

        current--  

        dequeue()  

      });  

  }  

}

这个函数用于从请求池中取出请求并发送。它在一个循环中运行，直到当前并发请求数current达到最大并发数concurrency或请求池queue为空。对于每个出队的请求，它首先增加current的值，然后调用请求函数requestPromiseFactory来发送请求。当请求完成（无论成功还是失败）后，它会减少current的值并再次调用dequeue，以便处理下一个请求。

定义返回请求入队函数

return (requestPromiseFactory) => {  

  queue.push(requestPromiseFactory) // 入队  

  dequeue()  

}

函数返回一个函数，这个函数接受一个参数requestPromiseFactory，表示一个返回Promise的请求工厂函数。这个返回的函数将请求工厂函数加入请求池queue，并调用dequeue来尝试发送新的请求，当然也可以自定义axios，利用Promise.all统一处理返回后的结果。

实验

const enqueue = requestQueue(6) // 设置最大并发数

for (let i = 0; i < reqs.length; i++) {  // 请求

  enqueue(() => axios.get('/api/test' + i))  

}

我们可以看到如上图所示,请求数确实被控制了，只有有请求响应成功的同时才会有新的请求进来，极大的降低里服务器的压力，后端的同学都只能喊6。

整合代码

import axios from 'axios'



export const handQueue = (

  reqs // 请求总数

) => {

  reqs = reqs || []





  const requestQueue = (concurrency) => {

    concurrency = concurrency || 6 // 最大并发数

    const queue = [] // 请求池

    let current = 0



    const dequeue = () => {

      while (current < concurrency && queue.length) {

        current++;

        const requestPromiseFactory = queue.shift() // 出列

        requestPromiseFactory()

          .then(() => { // 成功的请求逻辑

          })

          .catch(error => { // 失败

            console.log(error)

          })

          .finally(() => {

            current--

            dequeue()

          });

      }



    }



    return (requestPromiseFactory) => {

      queue.push(requestPromiseFactory) // 入队

      dequeue()

    }



  }



  const enqueue = requestQueue(6)



  for (let i = 0; i < reqs.length; i++) {



    enqueue(() => axios.get('/api/test' + i))

  }

}

实战文章

之前写过一篇关于web-worker大文件切片的案例文章，就是利用了此特性感兴趣的小伙伴可以看看web-worker的基本用法并进行大文件切片上传（附带简易node后端）

大家好，作为今年刚毕业的大聪明（小🐂🐎），知道今年不好就业，费心费力的面试终于进了个小公司，然后我的奇妙之旅开始了。

叮！闹钟响了！牙都不刷了，直接起床出门去上班，身为🐂🐎就要有早起吃草干活的觉悟，所以我是个很合格的食草动物。只不过，下面的信息，让我一天当动物的好心情都没了。

部署？因为该公司人数比较少，也没有自动化部署操作，只能让前端build一下dist包然后丢给后端，让后端部署，然后该项目也比较急，我刚来，也不好意思@后端，恰巧跟我对接的后端也是刚来不熟悉，所以我就跟负责人继续扯皮拖延时间了。（真是不好意思，假的）↓↓↓

终于经过不断努力（后端），部署好了，但是，我的样式乱了，为什么呢？看了一下网络和源代码，样式文件都请求到了，问了后端，一致说是我前端的问题，我懵了，然后快马加鞭查找问题

解决

ok，那我先看打包的dist文件有样式有问题吗，使用npm安装个 http-server 运行打包后的index.html，运行打开运行后的地址，欧克样式没乱，文件引用也没问题，那到底是什么鬼影响的呢？

在我百思不得其解的时候，我打开了神器--csdn，搜索打包dist部署后样式文件不生效，就遇到了这个神文t.csdnimg.cn/WbQyq
欧克，按照博主说的Nginx没有配置这两个东西而导致的，我有点不确定是不是，有点犹犹豫豫的找到后端说帮我在Nginx配置文件的http加下这两个配置，然后样式就好了，完美！后端由于疏忽，没加上就把问题推给我，结果被我扳回一城。

include   mime.types;

default_type  application/octet-stream;

总之，添加 include mime.types; 和 default_type application/octet-stream; 配置后，Nginx能够正确地识别和处理CSS文件的MIME类型，从而确保浏览器能够正确加载和应用CSS样式。

所以，前端仔不能只当前端仔，还是要好好学点服务端的知识，不然锅给你，你还认为这是你该背的锅。

以上是开玩笑的描述，只是为了吸引增加阅读量