哈喽，大家好！我是Web大鹅只会叫！下去沉淀了那么久，终于有时间回来给大家写点什么了！

你问我人为什么活着？我哪知道啊？我又不是上帝！释迦牟尼为了解这个问题还跑去出家，结果发现人活着就是为了涅槃——也就是死。所以别问我人生的意义，我也没搞明白！不过我能告诉你一个答案，那就是裸辞后，我终于知道了为什么要活着——那就是为了“活得自由”！

裸辞后，那些走过的路，和你说的“脏话”

2024年8月，我做了一个震惊所有人的决定——裸辞！是的，没错，我就是那种毫不犹豫地辞了职、丢下稳定收入和安稳生活，拿着背包去走四方的“疯子”。放下了每天早起20公里开车上班的压力，放下了无聊的加班、枯燥的开会，放下了所谓的“你要努力争取美好生活”的叮嘱。一切都在“离开”这一刻轻轻拂去，带着一种挥之不去的自由感。

带着亲人的责怪、朋友的疑问、同事的眼神、以及自己满满的疑惑，我开始了这段没有目的的旅行。我不知道我想找什么，但我知道，我不想再活得像以前那样。

我走过了无数地方，南京、湖州、宁波、杭州、义乌、金华、嘉兴、镇江、扬州、苏州、无锡、上海……一路走来，路过了每个风景，每个城市，每个人生。我甚至去了中国最北的漠河，站在寒风凛冽的雪地里，终于明白了一个道理：“你活着，才是最值得庆祝的事。

你知道吗，最让人清醒的，不是远方的景色，而是走出去之后，终于能脱离了那一套“你该做什么”的公式。每天不用设闹钟，不用准时吃饭，不用打卡上班，不用开会骂娘，再也不被地铁里的拥挤挤得喘不过气。生活突然变得宽松，我竟然开始意识到：我一直追求的美好生活，原来只是在为别人拼命。

走出内卷圈子的那一刻，我认为我是世界上最快乐的小孩了，我们渴望着幸福却糟践着现在，你所期望的美好未来却始终都是下一个阶段！你认为你是一个努力拼搏美好未来的人。可是现实比理想残酷的多！你没日没夜的拼搏，却让别人没日没夜的享受！你用尽自己半条命，换来的是下半辈子的病！我在裸辞后就告诉我自己：从今以后你想干什么、就干什么！你就是世界的主人！ 嗯～ 爽多了！

走过的路，都在暗示我

我在大兴安岭漠河市的市里住了5天，住在一个一天40元的宾馆、干净、暖和！老板是一个退休的铁道工人。脸和双手都布满了冻伤，他的妻子（大姨）很面善。每天都会在我回来的时候和我聊上几句从前，安排一些极寒天气的注意事项。

有一天我去北极村回来，大姨和我聊了一会。大姨对我讲：“趁年轻、别把自己困起来，出去走走。不像我们，60年没出过这片土地，到头还要葬在这片土地上！”。她说这句话的时候没有忧虑、没有悲伤，却是一种满足感。是啊！60多了，还能追求什么？忙了大半辈子，把孩子都送出了这片土地，自己也没有激情出去走走了，很害怕自己的以后也是这样。

我20多岁的年纪，想的不是努力拼搏挣钱、不是搞事业。却总想着无所事事。我觉得自己像一个没有完全“被时间遗弃”的人，我甚至觉得自己不属于这个时代，这个不知道为了什么而拼命的时代。每走一步都好像在掏空自己积压已久的情绪：压力、焦虑、焦灼，让我很享受这种感觉。然后我想起来一本书里的话：“你活着，不是为了活给别人看。“ 是啊，我们都明白这个大道理，可自己从来没打算让自己脱离这个主线。我开始明白，我这次的旅行不是去寻找什么，而是放下什么！

从别人嘴里听到的“脏话”，其实是自己内心的尖刺

这段时间里，我经常回想起来那些让我神经紧绷的日子。尤其是我对“人” 这个物种越来越敏感的那个时期————‘恶毒、自私、无理、肮脏’。朋友的欺骗、同事的推锅、亲人的折磨都是罪恶的！可是到头来，事情还是发生了。地球还是在自转，太阳一样正常升起落下。这些都没有在你认为的这些琐事中消失。我不明白我还在纠结什么？

事实上，这些乱七八糟的事情并不是指向我个人的，它只是我内心脆弱的反射。是的，我一直在内耗自己罢了，把自己放在了一个焦虑的漩涡里。假装没事、假装坚强，结果别人一句话就能作为击垮我的最后一击。直到有一天，我发现我讨厌的只是我自己。所以我决定我不要去在意别人说什么、做什么，我不要逃避问题，我想听听我内心的想法，我不想让自己认为别人在定义我。

过程的意义：也许就是为了“停一停”

好了，我知道我的文采不好，但是也应该有个结尾。

在这一路上，我认识了很多有趣的人，他们不同风格的服装、不同口音，各式各样的生活方式。也有着各式各样的理想和困惑。有的喜欢在山顶等着日出的奇迹，有的则是想在湖边静静地坐着。而我，就是个迷途的羔羊，没有群体头羊的带领，我穿行在这些不同的路途中，慢慢摸索着向所有方向前进着。

偶尔我也会停下来，坐在湖边吹着风、闭上眼睛，听风，感受这一刻的宁静。然后我会微笑，我认为这个时候的我有了轻松的感觉。生活的答案我在这个时候找到了。

我意识到，未来不是重要的，现在才是应该享受的。我不知道我下一步要去哪里，但是我想先停下来看一看，呼吸一下。停下来不是因为我没有了目的，而是我知道，目的地并不重要，重要的是，我和自己在一起，心里不再有那么多焦虑，不再被过去的焦虑所束缚。

所以，我选择了离开，离开这一切，放下所有的焦虑和期待，享受我自己想要的生活。也许，活着的意义不在于追寻一个遥远的目标，而是过好每一个‘现在’。

好人难当，以后要多注意了，涨点记性。记录三件事情证明下：

1. 免费劳动

之前和一个同学一起做一个项目，说是创业，不过项目做好了，倒是他家店铺自己用起来了，后来一直让我根据他家的需求进行修改，我也一一的改了，他倒是挺感谢我的，说是请吃饭。不过也一直没请，后面都一年多过去了，还让我免费帮他改需求，我就说没时间，他说没时间的话可以把源码给他，他自己学着修改，我就直接把源码给他了，这个项目辛苦了一个多月，钱一毛也没赚到，我倒是搭进去一台服务器，一年花了三百多吧。现在源码给他就给他了吧，毕竟同学一场。没想到又过了半年，前段时间又找我来改需求了。这个项目他们家自己拿着赚钱，又不给我一毛钱，我相当于免费给他家做了个软件，还要出服务器钱，还要免费进行维护。我的时间是真不值钱啊，真成义务劳动了。我拒绝了，理由是忙，没时间。

总结一下，这些人总会觉得别人帮自己是理所当然的，各种得寸进尺。

2. 帮到底吧

因为我进行了仲裁，有了经验，然后被一个人加了好友，是一个前同事（就是我仲裁的那家公司），然后这哥们各种问题我都尽心回答，本着能帮别人一点就帮别人一点的想法，但是我免费帮他，他仲裁到手多少钱，又不会给我一毛钱。这哥们一个问题接一个，我都做了回答，后来直接要求用我当做和公司谈判的筹码，我严词拒绝了，真不知道这人咋想的，我帮你并没有获得任何好处，你这个要求有点过分了，很简单，他直接把我搬出来和公司谈判，公司肯定会找我，会给我带来麻烦，这人一点也没想这些事。所以之后他再询问有关任何我的经验，我已经不愿意帮他了。

总结一下，这些人更进一步，甚至想利用下帮自己的人，不考虑会给别人带来哪些困扰。

3. 拿你顶缸

最近做了通过一个亲戚接了一个项目，而这个亲戚的表姐是该项目公司的领导，本来觉得都是有亲戚关系的，项目价格之类开始问了，他们没说，只是说根据每个人的工时进行估价，后面我们每个人提交了个人报价，然后还是一直没给明确答复，本着是亲戚的关系，觉得肯定不会坑我。就一直做下去了，直到快做完了，价格还是没有出来，我就直接问了这个价格的事情，第二天，价格出来了，在我报价基础上直接砍半。我当然不愿意了，后来经过各种谈判，我终于要到了一个勉强可以的价格，期间群里谈判也是我一个人在说话，团队的其他人都不说话。后来前端的那人问我价格，我也把过程都实话说了，这哥们也要加价，然后就各种问我，我也啥都告他了。后来这个前端在那个公司领导（亲戚表姐）主动亮明身份，她知道这个前端和那个亲戚关系好，然后这个前端立马不好意思加价了，并且还把锅甩我头上，说是我没有告诉他她是他姐。还说我不地道，我靠，你自己要加价，关我啥事，你加钱也没说要分我啊，另外我给自己加价的时候你也没帮忙说话啊，我告诉你我加价成功了是我好心，也是想着你能加点就加点吧，这时候你为了面子不加了，然后说成要加价的理由是因为我，真是没良心啊。后面还问我关于合同的事情，我已经不愿意回答他了，让他自己找对面公司问去。

总结一下，这些人你帮他了他当时倒是很感谢你，但是一旦结果有变，会直接怪罪到你头上。

4. 附录文章

这个文章说得挺好的《你的善良，要有锋芒》：

你有没有发现，善良的人，心都很软，他们不好意思拒绝别人，哪怕为难了自己，也要想办法帮助身边的人。善良的人，心都很细，他们总是照顾着别人的情绪，明明受委屈的是自己，却第一时间想着别人会不会难过。

也许是习惯了对别人好，你常常会忽略自己的感受。有时候你知道别人是想占你便宜，你也知道别人不是真心把你当朋友，他们只是觉得你好说话，只是看中了你的善良，但是你没有戳穿，你还是能帮就帮，没有太多怨言。

你说你不想得罪人，你说你害怕被孤立，可是有人在乎过你吗？

这个世界上形形色色的人很多，有人喜欢你，有人讨厌你，你没有办法做到对每一个人好，也没办法要求每一个人都是真心爱你。所以你要有自己的选择，与舒服的人相处，对讨厌的人远离，过你自己觉得开心自在的生活就好，没必要为了便利别人，让自己受尽委屈。

看过一段话：善良是很珍贵的，但善良要是没有长出牙齿来，那就是软弱。

你的善良，要有锋芒，不要把时间浪费在不值得的人身上。对爱你的人，倾心相助，对利用你的人，勇敢说不。

愿你的善良，能被真心的人温柔以待。

让闲置 Ubuntu 服务器华丽转身为家庭影院

在数字化的时代，家里的设备更新换代频繁，很容易就会有闲置的服务器吃灰。我家里就有一台闲置的 Ubuntu 24.04 服务器，一直放在角落，总觉得有些浪费。于是，我决定让它重新发挥作用，打造一个属于自己的家庭影院。

一、实现 Windows 与 Ubuntu 服务器文件互通

要打造家庭影院，首先得让本地 Windows 电脑和 Ubuntu 服务器之间能够方便地传输电影文件。我选择安装 Samba 来实现这一目的。

1. 安装 Samba：在 Ubuntu 服务器的终端中输入命令

   sudo apt-get install samba samba-common
   
   

   系统会自动下载并安装 Samba 相关的软件包。

2. 备份配置文件：为了以防万一，我先将原来的 Samba 配置文件进行备份，执行命令

   mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
   
   

3. 新建配置文件：使用 vim /etc/samba/smb.conf 命令打开编辑器，写入以下配置内容：

[global]

server min protocol = CORE

workgroup = WORKGR0UP

netbios name = Nas

security = user

map to guest = bad user

guest account = nobody

client min protocol = SMB2

server min protocol = SMB2

server smb encrypt = off

[NAS]

comment = NASserver

path = /home/bddxg/nas

public = Yes

browseable = Yes

writable = Yes

guest ok = Yes

passdb backend = tdbsam

create mask = 0775

directory mask = 0775

这里需要注意的是，我计划的媒体库目录是个人目录下的 nas/，所以 path 是 /home/bddxg/nas ，如果大家要部署的话记得根据自己的实际情况修改为对应的位置。 

4. 连接 Windows 电脑：在 Windows 电脑这边基本不需要什么复杂配置，因为在网络里无法直接看到 Ubuntu，我直接在电脑上添加了网络位置。假设服务器地址是 192.168.10.100，那么添加网络位置就是 \\192.168.10.100\nas，这样就可以在 Windows 电脑和 Ubuntu 服务器之间传输文件了。

二、安装 Jellyfin 搭建家庭影院

文件传输的问题解决后，接下来就是安装 Jellyfin 来实现家庭影院的功能了。

1. 尝试 Docker 安装失败：一开始我选择使用 Docker 安装，毕竟 Docker 有很多优点，使用起来也比较方便。按照官网指南进行操作，在第三步启动 Docker 并挂载本地目录的时候却一直失败。报错信息为:

   docker: Error response from daemon: error while creating mount source path '/srv/jellyfin/cache': mkdir /srv/jellyfin: read-only file system.
   
   

   即使我给 /srv/jellyfin 赋予了 777 权限也没有效果。无奈之下，我决定放弃 Docker 安装方式，直接安装 server 版本的 Jellyfin。

2. 安装 server 版本的 Jellyfin：在终端中输入命令 curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash，安装过程非常顺利。

3. 配置 Jellyfin：安装完成后，通过浏览器访问 http://192.168.10.100:8096 进入配置页面。在添加媒体库这里，我遇到了一个麻烦，网页只能选择到 /home/bddxg 目录，无法继续往下选择到我的媒体库位置 /home/bddxg/nas。于是我向 deepseek 求助，它告诉我需要执行命令:

   sudo usermod -aG bddxg jellyfin
   
   # 并且重启 Jellyfin 服务
   
   sudo systemctl restart jellyfin
   
   

   按照它的建议操作后，我刷新了网页，重新配置了 Jellyfin，终于可以正常添加媒体库了。

4. 电视端播放：在电视上安装好 Jellyfin apk 客户端后，现在终于可以正常读取 Ubuntu 服务器上的影视资源了，坐在沙发上，享受着大屏观影的乐趣，这种感觉真的太棒了！

 通过这次折腾，我成功地让闲置的 Ubuntu 服务器重新焕发生机，变成了一个功能强大的家庭影院。希望我的经验能够对大家有所帮助，也欢迎大家一起交流更多关于服务器利用和家庭影院搭建的经验。

[!WARNING] 令人遗憾的是,目前 jellyfin 似乎不支持rmvb 格式的影片, 下载资源的时候注意影片格式,推荐直接下载 mp4 格式的资源

---

本次使用到的软件名称和版本如下:

软件名	版本号	安装命令
samba	Version 4.19.5-Ubuntu	sudo apt-get install samba samba-common
jellyfin	Jellyfin.Server 10.10.6.0	curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash
ffmpeg(jellyfin 内自带)	ffmpeg version 7.0.2-Jellyfin	null

作者：冰冻大西瓜
来源：juejin.cn/post/7476614823883833382

在 MyBatis 中，如果 Mapper 接口的方法有多个参数，但没有使用 @Param 注解，默认情况下，MyBatis 会将这些参数放入一个 Map 中，键名为 param1、param2 等，或者使用索引 0、1 等来访问。以下是具体的使用方法和注意事项。

一、Mapper 接口方法

假设有一个 Mapper 接口方法，包含多个参数但没有使用 @Param 注解：

public interface UserMapper {

    User selectUserByNameAndAge(String name, int age);

}

二、XML 文件中的参数引用

在 XML 文件中，可以通过以下方式引用参数：

1. 使用 param1、param2 等

MyBatis 会自动为参数生成键名 param1、param2 等：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{param1} AND age = #{param2}

</select>

2. 使用索引 0、1 等

也可以通过索引 0、1 等来引用参数：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{0} AND age = #{1}

</select>

三、注意事项

四、示例代码

1. Mapper 接口

public interface UserMapper {

    User selectUserByNameAndAge(String name, int age);

}

2. XML 文件

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{param1} AND age = #{param2}

</select>

或者：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{0} AND age = #{1}

</select>

3. 测试代码

SqlSession sqlSession = sqlSessionFactory.openSession();

UserMapper mapper = sqlSession.getMapper(UserMapper.class);

User user = mapper.selectUserByNameAndAge("John", 25);

System.out.println(user);

sqlSession.close();

• 如果 Mapper 接口方法有多个参数且没有使用 @Param 注解，可以通过 param1、param2 或索引 0、1 等方式引用参数。


• 这种方式可读性较差，容易出错，推荐使用 @Param 注解明确参数名称。


• 使用 @Param 注解后，XML 文件中的参数引用会更加清晰和易于维护。

作为Java后端开发者转向游戏后端开发，虽然核心编程能力相通，但游戏开发在架构设计、协议选择、实时性处理等方面有显著差异。以下从实际工作流程角度详细说明游戏后端开发的核心要点及前后端协作流程：

一、游戏后端核心职责

二、开发全流程实战（以MMORPG为例）

阶段1：预研设计（2-4周）

• 协议设计
  

  // 使用Protobuf定义移动协议
  
  message PlayerMove {
  
    int32 player_id = 1;
  
    Vector3 position = 2;  // 三维坐标
  
    float rotation = 3;    // 朝向
  
    int64 timestamp = 4;   // 客户端时间戳
  
  }
  
  
  
  message BattleSkill {
  
    int32 skill_id = 1;
  
    repeated int32 target_ids = 2;  // 多目标锁定
  
    Coordinate cast_position = 3;   // 技能释放位置
  
  }
  
  

  
  


• 架构设计
  

  graph TD
  
    A[Gateway] --> B[BattleServer]
  
    A --> C[SocialServer]
  
    B --> D[RedisCluster]
  
    C --> E[MySQLCluster]
  
    F[MatchService] --> B
  
  

  
  

阶段2：核心系统开发（6-8周）

三、前后端协作关键点

四、性能优化实践

五、上线后运维

六、常见问题解决方案

问题场景：战斗不同步

排查步骤：

问题场景：登录排队

优化方案：

通过以上流程，Java后端开发者可逐步掌握游戏开发特性，重点需要转变的思维模式包括：从请求响应模式到实时状态同步、从CRUD主导到复杂逻辑计算、从分钟级延迟到毫秒级响应的要求。建议从简单的棋牌类游戏入手，逐步过渡到大型实时游戏开发。

大家好，我是 Java陈序员。

由于为了生活奔波，常年在外，导致很多关系稍疏远的亲戚之间来往并不多。

因此节假日回家时，往往会搞不清楚哪位亲戚应该喊什么称呼，很容易“社死”。

今天给大家介绍一个亲戚关系计算器，让你快速的计算出正确的亲戚称谓！

关注微信公众号：【Java陈序员】，获取开源项目分享、AI副业分享、超200本经典计算机电子书籍等。

项目介绍

relationship —— 中国亲戚关系计算器，只需简单的输入即可算出称谓。

输入框兼容了不同的叫法，你可以称呼父亲为：“老爸”、“爹地”、“老爷子”等等，方便不同地域的习惯叫法。

快捷输入按键，只需简单的点击即可完成关系输入，算法还支持逆向查找称呼哦～

功能特色：

• 使用别称查询：姥姥的爸爸的老窦 = 外曾外曾祖父


• 使用合称查询：姐夫的双亲 = 姊妹姻父 / 姊妹姻母


• 大小数字混合查询：大哥的二姑妈的七舅姥爷 = 舅曾外祖父


• 不限制祖辈孙辈跨度查询：舅妈的婆婆的外甥的姨妈的侄子 = 舅表舅父


• 根据年龄推导可能性：哥哥的表姐 = 姑表姐 / 舅表姐


• 根据语境确认性别：老婆的女儿的外婆 = 岳母


• 支持古文式表达：吾父之舅父 = 舅爷爷


• 解析某称谓关系链：七舅姥爷 = 妈妈的妈妈的兄弟


• 算两个亲戚间的合称关系：奶奶 + 外婆 = 儿女亲家

项目地址：

https://github.com/mumuy/relationship

在线体验：

https://passer-by.com/relationship/

移动端体验地址：

https://passer-by.com/relationship/vue/

功能体验

1、关系找称呼

2、称呼找关系

3、两者间关系

4、两者的合称

安装使用

1、直接引入安装

<script src="https://passer-by.com/relationship/dist/relationship.min.js">

获取全局方法 relationship.

2、使用 npm 包管理安装

安装依赖：

npm install relationship.js

包引入：

// CommonJS 引入

const relationship = require("relationship.js");

// ES Module 引入

import relationship from 'relationship.js';

3、使用方法：唯一的计算方法 relationship.

• 选项模式 relationship(options)
  
  

  构造函数：

  
  

  var options = {
  
      text:'',		// 目标对象：目标对象的称谓汉字表达，称谓间用‘的’字分隔
  
      target:'',	    // 相对对象：相对对象的称谓汉字表达，称谓间用‘的’字分隔，空表示自己
  
      sex:-1,			// 本人性别：0表示女性,1表示男性
  
      type:'default',	// 转换类型：'default'计算称谓,'chain'计算关系链,'pair'计算关系合称
  
      reverse:false,	// 称呼方式：true对方称呼我,false我称呼对方
  
      mode:'default',	// 模式选择：使用setMode方法定制不同地区模式，在此选择自定义模式
  
      optimal:false,  // 最短关系：计算两者之间的最短关系
  
  };
  
  

  
  

  代码示例：

  
  

  // 如：我应该叫外婆的哥哥什么？
  
  relationship({text:'妈妈的妈妈的哥哥'});
  
  // => ['舅外公']
  
  
  
  // 如：七舅姥爷应该叫我什么？
  
  relationship({text:'七舅姥爷',reverse:true,sex:1});
  
  // => ['甥外孙']
  
  
  
  // 如：舅公是什么亲戚
  
  relationship({text:'舅公',type:'chain'});
  
  // => ['爸爸的妈妈的兄弟', '妈妈的妈妈的兄弟', '老公的妈妈的兄弟']
  
  
  
  // 如：舅妈如何称呼外婆？
  
  relationship({text:'外婆',target:'舅妈',sex:1});
  
  // => ['婆婆']
  
  
  
  // 如：外婆和奶奶之间是什么关系？
  
  relationship({text:'外婆',target:'奶奶',type:'pair'});
  
  // => ['儿女亲家']
  
  

  
  


• 语句模式 relationship(exptession)
  
  

  
  

  参数 exptession 句式可以为：xxx是xxx的什么人、xxx叫xxx什么、xxx如何称呼xxx等。

  
  

  
  

  代码示例：

  
  

  // 如：舅妈如何称呼外婆？
  
  relationship('舅妈如何称呼外婆？');
  
  // => ['婆婆']
  
  
  
  // 如：外婆和奶奶之间是什么关系？
  
  relationship('外婆和奶奶之间是什么关系？');
  
  // => ['儿女亲家']
  
  

  
  

4、其他 API

// 获取当前数据表 

relationship.data



// 获取当前数据量 

relationship.dataCount



// 用户自定义模式 

relationship.setMode(mode_name,mode_data)

最后

推荐的开源项目已经收录到 GitHub 项目，欢迎 Star：

https://github.com/chenyl8848/great-open-source-project

或者访问网站，进行在线浏览：

https://chencoding.top:8090/#/

大家的点赞、收藏和评论都是对作者的支持，如文章对你有帮助还请点赞转发支持下，谢谢！

前言

在家没事的时候刷抖音玩，抖音首页的视频怎么刷也刷不完，经常不知不觉的一刷就到半夜了😅

不禁感叹道 ＂垃圾抖音，费我时间，毁我青春😅＂

这是我的 模仿抖音 系列文章的第二篇，本文将一步步实现抖音首页 视频无限滑动 的效果，干货满满

第一篇：200行代码实现类似Swiper.js的轮播组件

第三篇：Vue 路由使用介绍以及添加转场动画

第四篇：Vue 有条件路由缓存，就像传统新闻网站一样

第五篇：Github Actions 部署 Pages、同步到 Gitee、翻译 README 、 打包 docker 镜像

如果您对滑动原理不太熟悉，推荐先看我的这篇文章：200行代码实现类似Swiper.js的轮播组件

最终效果

在线预览：dy.ttentau.top/

Github地址：github.com/zyronon/dou…

源码：SlideVerticalInfinite.vue

实现原理

无限滑动的原理和虚拟滚动的原理差不多，要保持 SlideList 里面永远只有 N 个 SlideItem，就要在滑动时不断的删除和增加 SlideItem。

滑动时调整 SlideList 的偏移量 translateY 的值，以及列表里那几个 SlideItem 的 top 值，就可以了

为什么要调整 SlideList 的偏移量 translateY 的值同时还要调整 SlideItem 的 top 值呢？

因为 translateY 只是将整个列表移动，如果我们列表里面的元素是固定的，不会变多和减少，那么没关系，只调整　translateY 值就可以了，上滑了几页就减几页的高度，下滑同理

但是如果整个列表向前移动了一页，同时前面的 SlideItem 也少了一个，，那么最终效果就是移动了两页...因为 塌陷 了一页

这显然不是我们想要的，所以我们还需要同时调整 SlideItem 的 top 值，加上前面少的 SlideItem 的高度，这样才能显示出正常的内容

步骤

定义

virtualTotal：页面中同时存在多少个 SlideItem，默认为 5。

//页面中同时存在多少个SlideItem

virtualTotal: {

  type: Number,

  default: () => 5

},

设置这个值可以让外部组件使用时传入，毕竟每个人的需求不同，有的要求同时存在 10 条，有的要求同时存在 5 条即可。

不过同时存在的数量越大，使用体验就越好，即使用户快速滑动，我们依然有时间处理。

如果只同时存在 5 条，用户只需要快速滑动两次就到底了(因为屏幕中显示第 3 条，刚开始除外)，我们可能来不及添加新的视频到最后

render：渲染函数，SlideItem内显示什么由render返回值决定

render: {

  type: Function,

  default: () => {

    return null

  }

},

之所以要设定这个值，是因为抖音首页可不只有视频，还有图集、推荐用户、广告等内容，所以我们不能写死显示视频。

最好是定义一个方法，外部去实现，我们内部去调用，拿到返回值，添加到 SlideList 中

list：数据列表，外部传入

list: {

  type: Array,

  default: () => {

    return []

  }

},

我们从 list 中取出数据，然后调用并传给 render 函数，将其返回值插入到 SlideList中

初始化

watch(

  () => props.list,

  (newVal, oldVal) => {

    //新数据长度比老数据长度小，说明是刷新

    if (newVal.length < oldVal.length) {

      //从list中取出数据，然后调用并传给render函数，将其返回值插入到SlideList中

      insertContent()

    } else {

      //没数据就直接插入

      if (oldVal.length === 0) {

        insertContent()

      } else {

        // 走到这里，说明是通过接口加载了下一页的数据，

        // 为了在用户快速滑动时，无需频繁等待请求接口加载数据，给用户更好的使用体验

        // 这里额外加载3条数据。所以此刻，html里面有原本的5个加新增的3个，一共8个dom

        // 用户往下滑动时只删除前面多余的dom，等滑动到临界值（virtualTotal/2+1）时，再去执行新增逻辑

      }

    }

  }

)

用 watch 监听 list 是因为它一开始不一定有值，通过接口请求之后才有值

同时当我们下滑 加载更多 时，也会触发接口请求新的数据，用 watch 可以在有新数据时，多添加几条到 SlideList 的最后面，这样用户快速滑动也不怕了

如何滑动

这里就不再赘述，参考我的这篇文章：200行代码实现类似Swiper.js的轮播组件

滑动结束

判断滑动的方向

当我们向上滑动时,需要删除最前面的 dom ，然后在最后面添加一个 dom

下滑时反之

slideTouchEnd(e, state, canNext, (isNext) => {

  if (props.list.length > props.virtualTotal) {

    //手指往上滑(即列表展示下一条视频)

    if (isNext) {

      //删除最前面的 `dom` ，然后在最后面添加一个 `dom`  

    } else {

      //删除最后面的 `dom` ，然后在最前面添加一个 `dom`  

    }

  }

})

手指往上滑(即列表展示下一条视频)

• 首先判断是否要加载更多，快到列表末尾时就要加载更多数据了


• 再判断是否符合 腾挪 的条件，即当前位置要大于 half，且小于列表长度减 half。


• 在最后面添加一个 dom


• 删除最前面的 dom


• 将所有 dom 设置为最新的 top 值(原因前面有讲，因为删除了最前面的 dom，导致塌陷一页，所以要加上删除 dom 的高度)

let half = (props.virtualTotal - 1) / 2



//删除最前面的 `dom` ，然后在最后面添加一个 `dom`  

if (state.localIndex > props.list.length - props.virtualTotal && state.localIndex > half) {

  emit('loadMore')

}



//是否符合 `腾挪` 的条件

if (state.localIndex > half && state.localIndex < props.list.length - half) {

  //在最后面添加一个 `dom`  

  let addItemIndex = state.localIndex + half

  let res = slideListEl.value.querySelector(`.${itemClassName}[data-index='${addItemIndex}']`)

  if (!res) {

    slideListEl.value.appendChild(getInsEl(props.list[addItemIndex], addItemIndex))

  }



  //删除最前面的 `dom` 

  let index = slideListEl.value

    .querySelector(`.${itemClassName}:first-child`)

    .getAttribute('data-index')

  appInsMap.get(Number(index)).unmount()



  slideListEl.value.querySelectorAll(`.${itemClassName}`).forEach((item) => {

    _css(item, 'top', (state.localIndex - half) * state.wrapper.height)

  })

}

手指往下滑(即列表展示上一条视频)

逻辑和上滑都差不多，不过是反着来而已

• 再判断是否符合 腾挪 的条件，和上面反着


• 在最前面添加一个 dom


• 删除最后面的 dom


• 将所有 dom 设置为最新的 top 值

//删除最后面的 `dom` ，然后在最前面添加一个 `dom`

if (state.localIndex >= half && state.localIndex < props.list.length - (half + 1)) {

  let addIndex = state.localIndex - half

  if (addIndex >= 0) {

    let res = slideListEl.value.querySelector(`.${itemClassName}[data-index='${addIndex}']`)

    if (!res) {

      slideListEl.value.prepend(getInsEl(props.list[addIndex], addIndex))

    }

  }

  let index = slideListEl.value

    .querySelector(`.${itemClassName}:last-child`)

    .getAttribute('data-index')

  appInsMap.get(Number(index)).unmount()



  slideListEl.value.querySelectorAll(`.${itemClassName}`).forEach((item) => {

    _css(item, 'top', (state.localIndex - half) * state.wrapper.height)

  })

}

其他问题

为什么不直接用 v-for直接生成 SlideItem 呢?

如果内容不是视频就可以。要删除或者新增时，直接操作 list 数据源，这样省事多了

如果内容是视频，修改 list 时，Vue 会快速的替换 dom，正在播放的视频，突然一下从头开始播放了😅😅😅

如何获取 Vue 组件的最终 dom

有两种方式，各有利弊

• 用 Vue 的 render 方法
  
  
  
  • 优点：只是渲染一个 VNode 而已，理论上讲内存消耗更少。
  
  
  • 缺点：但我在开发中，用了这个方法，任何修改都会刷新页面，有点难蚌😅
  
  
  
  


• 用 Vue 的 createApp 方法再创建一个 Vue 的实例
  
  
  
  • 和上面相反😅
  
  
  
  

import { createApp, onMounted, reactive, ref, render as vueRender, watch } from 'vue'



/**

 * 获取Vue组件渲染之后的dom元素

 * @param item

 * @param index

 * @param play

 */

function getInsEl(item, index, play = false) {

  // console.log('index', cloneDeep(item), index, play)

  let slideVNode = props.render(item, index, play, props.uniqueId)

  const parent = document.createElement('div')

  //TODO 打包到线上时用这个，这个在开发时任何修改都会刷新页面

  if (import.meta.env.PROD) {

    parent.classList.add('slide-item')

    parent.setAttribute('data-index', index)

    //将Vue组件渲染到一个div上

    vueRender(slideVNode, parent)

    appInsMap.set(index, {

      unmount: () => {

        vueRender(null, parent)

        parent.remove()

      }

    })

    return parent

  } else {

    //创建一个新的Vue实例，并挂载到一个div上

    const app = createApp({

      render() {

        return <SlideItem data-index={index}>{slideVNode}</SlideItem>

      }

    })

    const ins = app.mount(parent)

    appInsMap.set(index, app)

    return ins.$el

  }

}

总结

原理其实并不难。主要是一开始可能会用 v-for 去弄，折腾半天发现不行。v-for 不行，就只能想想怎么把 Vue 组件搞到 html 里面去，又去研究如何获取 Vue 组件的最终 dom，又查了半天资料，Vue 官方文档也不写，还得去翻 api ，麻了

结束

以上就是文章的全部内容，感谢看到这里，希望对你有所帮助或启发！创作不易，如果觉得文章写得不错，可以点赞收藏支持一下，也欢迎关注我的公众号 前端张余让，我会更新更多实用的前端知识与技巧，期待与你共同成长~

需求

先来看这样一个场景，拿一个网站举例

这里有一个常见的网站 banner 图容器，大小为为1910*560，看起来背景图完美的充满了宽度，但是图片原始大小时，却是：

它的宽度只有 1440，且 background-size 设置的是 contain ，即等比例缩放，那么可以断定它两边的蓝色是依靠背景色填充的。

那么问题来了，这是一个 轮播banner，如果希望添加一张不是蓝色的图片呢？难道要给每张图片提前标注好背景颜色吗？这显然是非常死板的做法。

所以需要从图片中提取到图片的主题色，当然这对于 js 来说，也不是什么难事，市面上已经有众多的开源库供我们使用。

探索

首先在网络上找到了以下几个库：

• color-thief 这是一款基于 JavaScript 和 Canvas 的工具，能够从图像中提取主要颜色或代表性的调色板


• vibrant.js 该插件是 Android 支持库中 Palette 类的 JavaScript 版本，可以从图像中提取突出的颜色


• rgbaster.js 这是一段小型脚本，可以获取图片的主色、次色等信息，方便实现一些精彩的 Web 交互效果

我取最轻量化的 rgbaster.js（此库非常搞笑，用TS编写，npm 包却没有指定 types） 来测试后发现，它给我在一个渐变色图片中，返回了七万多个色值，当然，它准确的提取出了面积最大的色值，但是这个色值不是图片边缘的颜色，导致设置为背景色后，并不能完美的融合。

另外的插件各位可以参考这几篇文章：

• 文章1：blog.csdn.net/weixin_4299…


• 文章2：juejin.cn/post/684490…


• 文章3：http://www.zhangxinxu.com/wordpress/2…

可以发现，这些插件主要功能就是取色，并没有考虑实际的应用场景，对于一个图片颜色分析工具来说，他们做的很到位，但是在大多数场景中，他们往往是不适用的。

在文章 2 中，作者对比了三款插件对于图片容器背景色的应用，看起来还是 rgbaster 效果好一点，但是我们刚刚也拿他试了，它并不能适用于颜色复杂度高的、渐变色的图片。

思考

既然又又又没有人做这件事，正所谓我不入地狱谁入地狱，我手写一个

整理一下需求，我发现我希望得到的是：

这样一来，就已经可以覆盖大部分需求了，1+2 可以生成相关的 主题 TAG、主题背景，3 可以使留白的图片容器完美融合。

开搞

⚠⚠ 本小节内容非常硬核，如果不想深究原理可以直接跳过，文章末尾有用法和效果图 ⚠⚠

思路

首先需要避免上面提到的插件的缺点，即对渐变图片要做好处理，不能取出成千上万的颜色，体验太差且实用性不强，对于渐变色还有一点，即在渐变路径上，每一点的颜色都是不一样的，所以需要将他们以一个阈值分类，挑选出一众相近色，并计算出一个平均色，这样就不会导致主题色太精准进而没有代表性。

对于背景色，需要按情况分析，如果只是希望做一个协调的页面，那么大可以直接使用主题色做渐变过渡或蒙层，也就是类似于这种效果

但是如果希望背景与图片完美衔接，让人看不出图片边界的感觉，就需要单独对边缘颜色取色了。

最后一个问题，如果图片分辨率过大，在遍历像素点时会非常消耗性能，所以需要降低采样率，虽然会导致一些精度上的丢失，但是调整为一个合适的值后应该基本可用。

剩余的细节问题，我会在下面的代码中解释

使用 JaveScript 编码

接下来我将详细描述 autohue.js 的实现过程，由于本人对色彩科学不甚了解，如有解释不到位或错误，还请指出。

首先编写一个入口主函数，我目前考虑到的参数应该有：

export default async function colorPicker(imageSource: HTMLImageElement | string, options?: autoColorPickerOptions)

type thresholdObj = { primary?: number; left?: number; right?: number; top?: number; bottom?: number }

interface autoColorPickerOptions {

  /**

   * - 降采样后的最大尺寸（默认 100px）

   * - 降采样后的图片尺寸不会超过该值，可根据需求调整

   * - 降采样后的图片尺寸越小，处理速度越快，但可能会影响颜色提取的准确性

   **/

  maxSize?: number

  /**

   * - Lab 距离阈值（默认 10）

   * - 低于此值的颜色归为同一簇，建议 8~12

   * - 值越大，颜色越容易被合并，提取的颜色越少

   * - 值越小，颜色越容易被区分，提取的颜色越多

   **/

  threshold?: number | thresholdObj

}

概念解释 Lab ，全称：CIE L*a*b ，CIE L*a*b* 是CIE XYZ色彩模式的改进型。它的“L”（明亮度），“a”（绿色到红色）和“b”（蓝色到黄色）代表许多的值。与XYZ比较，CIE L*a*b*的色彩更适合于人眼感觉的色彩，正所谓感知均匀

然后需要实现一个正常的 loadImg 方法，使用 canvas 异步加载图片

function loadImage(imageSource: HTMLImageElement | string): Promise<HTMLImageElement> {

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

    let img: HTMLImageElement

    if (typeof imageSource === 'string') {

      img = new Image()

      img.crossOrigin = 'Anonymous'

      img.src = imageSource

    } else {

      img = imageSource

    }

    if (img.complete) {

      resolve(img)

    } else {

      img.onload = () => resolve(img)

      img.onerror = (err) => reject(err)

    }

  })

}

这样我们就获取到了图片对象。

然后为了图片过大，我们需要进行降采样处理

// 利用 Canvas 对图片进行降采样，返回 ImageData 对象

function getImageDataFromImage(img: HTMLImageElement, maxSize: number = 100): ImageData {

  const canvas = document.createElement('canvas')

  let width = img.naturalWidth

  let height = img.naturalHeight

  if (width > maxSize || height > maxSize) {

    const scale = Math.min(maxSize / width, maxSize / height)

    width = Math.floor(width * scale)

    height = Math.floor(height * scale)

  }

  canvas.width = width

  canvas.height = height

  const ctx = canvas.getContext('2d')

  if (!ctx) {

    throw new Error('无法获取 Canvas 上下文')

  }

  ctx.drawImage(img, 0, 0, width, height)

  return ctx.getImageData(0, 0, width, height)

}

概念解释，降采样：降采样（Downsampling）是指在图像处理中，通过减少数据的采样率或分辨率来降低数据量的过程。具体来说，就是在保持原始信息大致特征的情况下，减少数据的复杂度和存储需求。这里简单理解为将图片强制压缩为 100*100 以内，也是 canvas 压缩图片的常见做法。

得到图像信息后，就可以对图片进行像素遍历处理了，正如思考中提到的，我们需要对相近色提取并取平均色，并最终获取到主题色、次主题色。

那么问题来了，什么才算相近色，对于这个问题，在 常规的 rgb 中直接计算是不行的，因为它涉及到一个感知均匀的问题

概念解释，感知均匀：XYZ系统和在它的色度图上表示的两种颜色之间的距离与颜色观察者感知的变化不一致，这个问题叫做感知均匀性(perceptual uniformity)问题，也就是颜色之间数字上的差别与视觉感知不一致。由于我们需要在颜色簇中计算出平均色，那么对于人眼来说哪些颜色是相近的？此时，我们需要把 sRGB 转化为 Lab 色彩空间（感知均匀的），再计算其欧氏距离，在某一阈值内的颜色，即可认为是相近色。

所以我们首先需要将 rgb 转化为 Lab 色彩空间

// 将 sRGB 转换为 Lab 色彩空间

function rgbToLab(r: number, g: number, b: number): [number, number, number] {

  let R = r / 255,

    G = g / 255,

    B = b / 255

  R = R > 0.04045 ? Math.pow((R + 0.055) / 1.055, 2.4) : R / 12.92

  G = G > 0.04045 ? Math.pow((G + 0.055) / 1.055, 2.4) : G / 12.92

  B = B > 0.04045 ? Math.pow((B + 0.055) / 1.055, 2.4) : B / 12.92



  let X = R * 0.4124 + G * 0.3576 + B * 0.1805

  let Y = R * 0.2126 + G * 0.7152 + B * 0.0722

  let Z = R * 0.0193 + G * 0.1192 + B * 0.9505



  X = X / 0.95047

  Y = Y / 1.0

  Z = Z / 1.08883



  const f = (t: number) => (t > 0.008856 ? Math.pow(t, 1 / 3) : 7.787 * t + 16 / 116)

  const fx = f(X)

  const fy = f(Y)

  const fz = f(Z)

  const L = 116 * fy - 16

  const a = 500 * (fx - fy)

  const bVal = 200 * (fy - fz)

  return [L, a, bVal]

}

这个函数使用了看起来很复杂的算法，不必深究，这是它的大概解释：

接下来实现聚类算法

/**

 * 对满足条件的像素进行聚类

 * @param imageData 图片像素数据

 * @param condition 判断像素是否属于指定区域的条件函数（参数 x, y）

 * @param threshold Lab 距离阈值，低于此值的颜色归为同一簇，建议 8~12

 */

function clusterPixelsByCondition(imageData: ImageData, condition: (x: number, y: number) => boolean, threshold: number = 10): Cluster[] {

  const clusters: Cluster[] = []

  const data = imageData.data

  const width = imageData.width

  const height = imageData.height

  for (let y = 0; y < height; y++) {

    for (let x = 0; x < width; x++) {

      if (!condition(x, y)) continue

      const index = (y * width + x) * 4

      if (data[index + 3] === 0) continue // 忽略透明像素

      const r = data[index]

      const g = data[index + 1]

      const b = data[index + 2]

      const lab = rgbToLab(r, g, b)

      let added = false

      for (const cluster of clusters) {

        const d = labDistance(lab, cluster.averageLab)

        if (d < threshold) {

          cluster.count++

          cluster.sumRgb[0] += r

          cluster.sumRgb[1] += g

          cluster.sumRgb[2] += b

          cluster.sumLab[0] += lab[0]

          cluster.sumLab[1] += lab[1]

          cluster.sumLab[2] += lab[2]

          cluster.averageRgb = [cluster.sumRgb[0] / cluster.count, cluster.sumRgb[1] / cluster.count, cluster.sumRgb[2] / cluster.count]

          cluster.averageLab = [cluster.sumLab[0] / cluster.count, cluster.sumLab[1] / cluster.count, cluster.sumLab[2] / cluster.count]

          added = true

          break

        }

      }

      if (!added) {

        clusters.push({

          count: 1,

          sumRgb: [r, g, b],

          sumLab: [lab[0], lab[1], lab[2]],

          averageRgb: [r, g, b],

          averageLab: [lab[0], lab[1], lab[2]]

        })

      }

    }

  }

  return clusters

}

函数内部有一个 labDistance 的调用，labDistance 是计算 Lab 颜色空间中的欧氏距离的

// 计算 Lab 空间的欧氏距离

function labDistance(lab1: [number, number, number], lab2: [number, number, number]): number {

  const dL = lab1[0] - lab2[0]

  const da = lab1[1] - lab2[1]

  const db = lab1[2] - lab2[2]

  return Math.sqrt(dL * dL + da * da + db * db)

}

概念解释，欧氏距离：Euclidean Distance，是一种在多维空间中测量两个点之间“直线”距离的方法。这种距离的计算基于欧几里得几何中两点之间的距离公式，通过计算两点在各个维度上的差的平方和，然后取平方根得到。欧氏距离是指n维空间中两个点之间的真实距离，或者向量的自然长度（即该点到原点的距离）。

总的来说，这个函数采用了类似 K-means 的聚类方式，将小于用户传入阈值的颜色归为一簇，并取平均色(使用 Lab 值)。

概念解释，聚类算法：Clustering Algorithm 是一种无监督学习方法，其目的是将数据集中的元素分成不同的组（簇），使得同一组内的元素相似度较高，而不同组之间的元素相似度较低。这里是将相近色归为一簇。

概念解释，颜色簇：簇是聚类算法中一个常见的概念，可以大致理解为 "一类"

得到了颜色簇集合后，就可以按照count大小来判断哪个是主题色了

  // 对全图所有像素进行聚类

  let clusters = clusterPixelsByCondition(imageData, () => true, threshold.primary)

  clusters.sort((a, b) => b.count - a.count)

  const primaryCluster = clusters[0]

  const secondaryCluster = clusters.length > 1 ? clusters[1] : clusters[0]

  const primaryColor = rgbToHex(primaryCluster.averageRgb)

  const secondaryColor = rgbToHex(secondaryCluster.averageRgb)

现在我们已经获取到了主题色、次主题色 🎉🎉🎉

接下来，我们继续计算边缘颜色

按照同样的方法，只是把阈值设小一点，我这里直接设置为 1 （threshold.top 等都是1）

  // 分别对上、右、下、左边缘进行聚类

  const topClusters = clusterPixelsByCondition(imageData, (_x, y) => y < margin, threshold.top)

  topClusters.sort((a, b) => b.count - a.count)

  const topColor = topClusters.length > 0 ? rgbToHex(topClusters[0].averageRgb) : primaryColor



  const bottomClusters = clusterPixelsByCondition(imageData, (_x, y) => y >= height - margin, threshold.bottom)

  bottomClusters.sort((a, b) => b.count - a.count)

  const bottomColor = bottomClusters.length > 0 ? rgbToHex(bottomClusters[0].averageRgb) : primaryColor



  const leftClusters = clusterPixelsByCondition(imageData, (x, _y) => x < margin, threshold.left)

  leftClusters.sort((a, b) => b.count - a.count)

  const leftColor = leftClusters.length > 0 ? rgbToHex(leftClusters[0].averageRgb) : primaryColor



  const rightClusters = clusterPixelsByCondition(imageData, (x, _y) => x >= width - margin, threshold.right)

  rightClusters.sort((a, b) => b.count - a.count)

  const rightColor = rightClusters.length > 0 ? rgbToHex(rightClusters[0].averageRgb) : primaryColor

这样我们就获取到了上下左右四条边的颜色 🎉🎉🎉

这样大致的工作就完成了，最后我们将需要的属性导出给用户，我们的主函数最终长这样：

/**

 * 主函数：根据图片自动提取颜色

 * @param imageSource 图片 URL 或 HTMLImageElement

 * @returns 返回包含主要颜色、次要颜色和背景色对象（上、右、下、左）的结果

 */

export default async function colorPicker(imageSource: HTMLImageElement | string, options?: autoColorPickerOptions): Promise<AutoHueResult> {

  const { maxSize, threshold } = __handleAutoHueOptions(options)

  const img = await loadImage(imageSource)

  // 降采样（最大尺寸 100px，可根据需求调整）

  const imageData = getImageDataFromImage(img, maxSize)



  // 对全图所有像素进行聚类

  let clusters = clusterPixelsByCondition(imageData, () => true, threshold.primary)

  clusters.sort((a, b) => b.count - a.count)

  const primaryCluster = clusters[0]

  const secondaryCluster = clusters.length > 1 ? clusters[1] : clusters[0]

  const primaryColor = rgbToHex(primaryCluster.averageRgb)

  const secondaryColor = rgbToHex(secondaryCluster.averageRgb)



  // 定义边缘宽度（单位像素）

  const margin = 10

  const width = imageData.width

  const height = imageData.height



  // 分别对上、右、下、左边缘进行聚类

  const topClusters = clusterPixelsByCondition(imageData, (_x, y) => y < margin, threshold.top)

  topClusters.sort((a, b) => b.count - a.count)

  const topColor = topClusters.length > 0 ? rgbToHex(topClusters[0].averageRgb) : primaryColor



  const bottomClusters = clusterPixelsByCondition(imageData, (_x, y) => y >= height - margin, threshold.bottom)

  bottomClusters.sort((a, b) => b.count - a.count)

  const bottomColor = bottomClusters.length > 0 ? rgbToHex(bottomClusters[0].averageRgb) : primaryColor



  const leftClusters = clusterPixelsByCondition(imageData, (x, _y) => x < margin, threshold.left)

  leftClusters.sort((a, b) => b.count - a.count)

  const leftColor = leftClusters.length > 0 ? rgbToHex(leftClusters[0].averageRgb) : primaryColor



  const rightClusters = clusterPixelsByCondition(imageData, (x, _y) => x >= width - margin, threshold.right)

  rightClusters.sort((a, b) => b.count - a.count)

  const rightColor = rightClusters.length > 0 ? rgbToHex(rightClusters[0].averageRgb) : primaryColor



  return {

    primaryColor,

    secondaryColor,

    backgroundColor: {

      top: topColor,

      right: rightColor,

      bottom: bottomColor,

      left: leftColor

    }

  }

}

还记得本小节一开始提到的参数吗，你可以自定义 maxSize（压缩大小，用于降采样）、threshold（阈值，用于设置簇大小）

为了用户友好，我还编写了 threshold 参数的可选类型：number | thresholdObj

type thresholdObj = { primary?: number; left?: number; right?: number; top?: number; bottom?: number }

可以单独设置主阈值、上下左右四边阈值，以适应更个性化的情况。

autohue.js 诞生了

名字的由来：秉承一贯命名习惯，auto 家族成员又多一个，与颜色有关的单词有好多个，我取了最短最好记的一个 hue(色相)，也比较契合插件用途。

此插件已在 github 开源：GitHub autohue.js

npm 主页：NPM autohue.js

在线体验：autohue.js 官方首页

安装与使用

pnpm i autohue.js

import autohue from 'autohue.js'



autohue(url, {

  threshold: {

    primary: 10,

    left: 1,

    bottom: 12

  },

  maxSize: 50

})

  .then((result) => {

    // 使用 console.log 打印出色块元素s

    console.log(`%c${result.primaryColor}`, 'color: #fff; background: ' + result.primaryColor, 'main')

    console.log(`%c${result.secondaryColor}`, 'color: #fff; background: ' + result.secondaryColor, 'sub')

    console.log(`%c${result.backgroundColor.left}`, 'color: #fff; background: ' + result.backgroundColor.left, 'bg-left')

    console.log(`%c${result.backgroundColor.right}`, 'color: #fff; background: ' + result.backgroundColor.right, 'bg-right')

    console.log(`%clinear-gradient to right`, 'color: #fff; background: linear-gradient(to right, ' + result.backgroundColor.left + ', ' + result.backgroundColor.right + ')', 'bg')

    bg.value = `linear-gradient(to right, ${result.backgroundColor.left}, ${result.backgroundColor.right})`

  })

  .catch((err) => console.error(err))

最终效果

复杂边缘效果

纵向渐变效果（这里使用的是 left 和 right 边的值，可能使用 top 和 bottom 效果更佳）

纯色效果（因为单独对边缘采样，所以无论图片内容多复杂，纯色基本看不出边界）

突变边缘效果（此时用css做渐变蒙层应该效果会更好）

横向渐变效果（使用的是 left 和 right 的色值），基本看不出边界

参考资料

• zhuanlan.zhihu.com/p/370371059


• baike.baidu.com/item/%E5%9B…


• baike.baidu.com/item/%E6%A0…


• zh.wikipedia.org/wiki/%E6%AC…


• blog.csdn.net/weixin_4256…


• zh.wikipedia.org/wiki/K-%E5%…


• blog.csdn.net/weixin_4299…


• juejin.cn/post/684490…

番外

Auto 家族的其他成员

• Auto-Plugin/autofit.js autofit.js 迄今为止最易用的自适应工具


• Auto-Plugin/autolog.js autolog.js 轻量化小弹窗


• Auto-Plugin/autouno autouno 直觉的UnoCSS预设方案


• Auto-Plugin/autohue.js 本品 一个自动提取图片主题色让图片和背景融为一体的工具

😃文章首发于公众号[精益码农]。

闭包作为前端面试的必考题目，常让1-3年工作经验的Javascripter感到困惑，我的主力语言C#/GO均有闭包。

1. 闭包：关键点在于函数是否捕获了其外部作用域的变量

闭包的形成： 定义函数时， 函数引用了其外部作用域的变量， 之后就形成了闭包。

闭包的结果： 引用的变量和定义的函数都会一同存在（即使已经脱离了函数定义/引用的变量的作用域），一直到闭包被消灭。

    public  static Action Closure()

    {

      var x = 1;

      Action action= () =>

         {

             var y = 1;

             var result = x + y;

             Console.WriteLine(result);

             x++;

         };

         return action;

    }



public static void  Main() {

       var  a=Closure();

        a();

        a();

}

 //  调用函数输出

  2

  3

委托action是一个函数，它使用了“x”这个外部作用域的变量（x变量不是函数内局部变量），变量引用将被捕获形成闭包。

即使action被返回了（即使“x”已经脱离了它被引用时的作用域环境（Closure）），但是两次执行能输出2,3 说明它脱离原引用环境仍然能用。

当你在代码调试器（debugger）里观察“action”时，可以看到一个Target属性，里面封装了捕获的x变量：

实际上，委托，匿名函数和lambda都是继承自Delegate类，
Delegate不允许开发者直接使用，只有编译器才能使用， 也就是说delegate Action都是语法糖。

• Method：MethodInfo反射类型- 方法执行体


• Target：当前委托执行的对象，这些语法糖由编译器生成了继承自Delegate类型的对象，包含了捕获的自由变量。

再给一个反例：

public class Program

{

    private static int x = 1; // 静态字段

    public static void Main()

    {

        var  action = NoClosure();

        action();

        action(); 

    }

    

   public  static Action NoClosure(){

        Action action=()=>{

            var  y =1;

            var sum = x+y;

            Console.WriteLine($"sum = { sum }");

            x++;

        };

        return action;

    }

}

x 是静态字段，在程序中有独立的存储区域， 不在线程的函数堆栈区，不属于某个特定的作用域。

匿名函数使用了 x，但没有捕获外部作用域的变量，因此不构成闭包， Target属性对象无捕获的字段。

从编程设计的角度：闭包开创了除全局变量传值， 函数参数传值之外的第三种变量使用方式。

2. 闭包的形成时机和效果

闭包是词法闭包的简称，维基百科上是这样定义的：

“在计算机科学中，闭包是在词法环境中绑定自由变量的一等函数”。

闭包的形成时机：

• 一等函数


• 外部作用域变量

闭包的形态：

会捕获闭包函数内引用的外部作用域变量， 一直持有，直到闭包函数不再使用被销毁。

内部实现是形成了一个对象(包含执行函数和捕获的变量，参考Target对象), 只有形成堆内存，才有后续闭包销毁的行为，当闭包这个对象不再被引用时，闭包被GC清理。

闭包的作用周期：

离不开作用域这个概念，函数理所当然管控了函数内的局部变量作用域，但当它引用了外部有作用域的变量时， 就形成了闭包函数。
当闭包（例如一个委托或 lambda 表达式）不再被任何变量、对象或事件持有引用时，它就变成了“不可达”对象， 闭包被gc清理，其实就是堆内存被清理。

2.1 一等函数

一等函数很容易理解，就是在各语言， 函数被认为是某类数据类型， 定义函数就成了定义变量， 函数也可以像变量一样被传递。

很明显，在C#中我们常使用的匿名函数、lambda表达式都是一等函数。

Func<string,string> myFunc = delegate(string var1)

                                {

                                    return "some value";   

                                };

Func<string,string> myFunc = var1 => "some value";  



string myVar = myFunc("something");

2.2 自由变量

在函数中被引用的外部作用域变量， 注意， 这个变量是外部有作用域的变量，也就说排除全局变量（这些变量在程序的独立区域， 不属于任何作用域）。

public void Test() 

{

       var myVar = "this is good";

       Func<string,string> myFunc = delegate(string var1)

                                {

                                    return var1 + myVar;   

                                };

}

上面这个示例，myFunc形成了闭包，捕获了myVar这个外部作用域的变量；
即使Test函数返回了委托myFunc（脱离了定义myVar变量的作用域），闭包依然持有myVar的变量引用，
注意，引用变量，并不是使用当时变量的副本值。

我们再回过头来看结合了线程调度的闭包面试题。

3. 闭包函数关联线程调度： 依次打印连续的数字

 static void Closure1()

{

    for (int i = 0; i < 10; i++)

    {                 

         Task.Run(()=> Console.WriteLine(i));

    }

 }

每次输出数字不固定

并不是预期的 0.1.2.3.4.5.6.7.8.9

首先形成了闭包函数()=> Console.WriteLine(i)， 捕获了外部有作用域变量i的引用, 此处捕获的变量i相对于函数是全局变量。
但是Task调度闭包函数的时机不确定， 所以打印的是被调度时引用的变量i值。

数字符合但乱序：为每个闭包函数绑定独立变量

循环内增加局部变量， 解绑全局变量 （或者可以换成foreach，foreach相当于内部给你整了一个局部变量）。

能输出乱序的0,1,2,3,4,5,6,7,8,9

因为每次循环内产生的闭包函数捕获了对应的局部变量j，这样每个任务执行环境均独立维护了一个变量j， 这个j不是全局变量, 但是由于Task启动时机依然不确定，故是乱序。

数字符合且有序

核心是解决 Task调度问题。

思路是：一个共享变量，每个任务打印该变量自增的一个阶段，但是该自增不允许被打断。

 public static void Main(string[] args)

    {

        var s =0;

        var  lo = new Program();

        for (int i = 0; i < 10; i++)

        {              

           Task.Run(()=> 

            { 

                lock(lo)

                {

                    Console.WriteLine(s);   // 依然形成了闭包函数， 之后闭包函数被线程调度

                    s++;

                }                

            });

        }

        Thread.Sleep(2000);

    }  // 上面是一个明显的锁争用

3.Golang闭包的应用

gin 框架中中间件的默认形态是：

package middleware

func AuthenticationMiddleware(c *gin.Context) {

   ......

}



 //  Use方法的参数签名是这样：  type HandlerFunc func(*Context)， 不支持入参

router.Use(middleware.AuthenticationMiddleware)   

实际实践上我们又需要给中间件传参， 闭包提供了这一能力。

func Authentication2Middleware(log *zap.Logger) gin.HandlerFunc  {

     return func(c *gin.Context) { 

         ...    这里面可以利用log 参数。

     }

}



var logger  *zap.Logger

api.Use(middleware.Authentication2Middleware(logger))

总结

本文屏蔽语言差异，理清了[闭包]的概念核心： 函数引用了其外部作用域的变量，

核心特征：一等函数、自由变量，核心结果： 即使脱离了原捕获变量的原作用域，闭包函数依然持有该变量引用。

不仅能帮助我们应对多语种有关闭包的面试题， 也帮助我们了解[闭包]在通用语言中的设计初衷。

另外我们通过C# 调试器巩固了Delegate 抽象类，这是lambda表达式,委托，匿名函数的底层抽象数据结构类，包含两个重要属性 Method Target，分别表征了方法执行体、当前委托作用的对象，

可想而知，其他语言也是通过这个机制捕获闭包当中的自由变量。

一、为什么需要AI代码审查？

写代码就像做饭，即使是最有经验的厨师（程序员），也难免会忘记关火（资源未释放）、放错调料（逻辑错误）或者切到手（空指针异常）。Deepseek就像一位24小时待命的厨房监理，能帮我们实时发现这些"安全隐患"。

二、环境准备（5分钟搞定）

1. 安装Deepseek插件（以VSCode为例）：

• • 插件市场搜索"Deepseek Code Review"
  • 点击安装（就像安装手机APP一样简单）

2. Java项目配置：

<dependency>

    <groupId>com.deepseekgroupId>

    <artifactId>code-analyzerartifactId>

    <version>1.3.0version>

dependency>

三、真实案例：用户管理系统漏洞检测

原始问题代码：

public class UserService {

    // 漏洞1：未处理空指针

    public String getUserRole(String userId) {

        return UserDB.query(userId).getRole();

    }



    // 漏洞2：资源未关闭

    public void exportUsers() {

        FileOutputStream fos = new FileOutputStream("users.csv");

        fos.write(getAllUsers().getBytes());

    }



    // 漏洞3：SQL注入风险

    public void deleteUser(String input) {

        Statement stmt = conn.createStatement();

        stmt.execute("DELETE FROM users WHERE id = " + input);

    }

}

使用Deepseek审查后：

智能修复建议：

1. 空指针防护 → 建议添加Optional处理
2. 流资源 → 推荐try-with-resources语法
3. SQL注入 → 提示改用PreparedStatement

修正后的代码：

public class UserService {

    // 修复1：Optional处理空指针

    public String getUserRole(String userId) {

        return Optional.ofNullable(UserDB.query(userId))

                      .map(User::getRole)

                      .orElse("guest");

    }



    // 修复2：自动资源管理

    public void exportUsers() {

        try (FileOutputStream fos = new FileOutputStream("users.csv")) {

            fos.write(getAllUsers().getBytes());

        }

    }



    // 修复3：预编译防注入

    public void deleteUser(String input) {

        PreparedStatement pstmt = conn.prepareStatement(

            "DELETE FROM users WHERE id = ?");

        pstmt.setString(1, input);

        pstmt.executeUpdate();

    }

}

四、实现原理揭秘

Deepseek的代码审查就像"X光扫描仪"，通过以下三步工作：

1. 模式识别：比对数千万个代码样本

• • 就像老师批改作业时发现常见错误

2. 上下文理解：分析代码的"人际关系"

• • 数据库连接有没有"成对出现"（打开/关闭）
  • 敏感操作有没有"保镖"（权限校验）

3. 智能推理：预测代码的"未来"

• • 这个变量走到这里会不会变成null？
  • 这个循环会不会变成"无限列车"？

五、进阶使用技巧

1. 自定义审查规则（配置文件示例）：

rules:

  security:

    sql_injection: error

  performance:

    loop_complexity: warning

  style:

    var_naming: info

2. 与CI/CD集成（GitHub Action示例）：

- name: Deepseek Code Review

  uses: deepseek-ai/code-review-action@v2

  with:

    severity_level: warning

    fail_on: error

六、开发者常见疑问

Q：AI会不会误判我的代码？
A：就像导航偶尔会绕路，Deepseek给出的是"建议"而非"判决"，最终决策权在你手中

Q：处理历史遗留项目要多久？
A：10万行代码项目约需3-5分钟，支持增量扫描

七、效果对比数据

指标	人工审查	Deepseek+人工
平均耗时	4小时	30分钟
漏洞发现率	78%	95%
误报率	5%	12%
知识库更新速度	季度	实时

作者：Java技术小馆
来源：juejin.cn/post/7473799336675639308

看到Matt Pocock 在 X 上的一个帖子提到不使用 .d.ts 文件的说法。

你赞同么？是否也应该把 .d.ts 文件都替换为 .ts 文件呢？

我们一起来看看~

.d.ts 文件的用途

首先，我们要澄清的是，.d.ts 文件并不是毫无用处的。

.d.ts 文件的用途主要用于为 JavaScript 代码提供类型描述。

.d.ts 文件是严格的蓝图，用于表示你的源代码可以使用的类型。最早可以追溯到2012年。其设计受到头文件、接口描述语言（IDL）、JSDoc 等实践的启发，可以被视为 TypeScript 版本的头文件。

.d.ts 文件只能包含声明，所以让我们通过一个代码示例来看看声明和实现之间的区别。假设我们有一个函数，它将两个数字相加：

// 声明 (.d.ts)

export function add(num1: number, num2: number): number;

// 实现 (.ts)

export function add(num1: number, num2: number): number {

  return num1 + num2;

}

正如你所见，add 函数的实现实际上展示了加法的执行过程，并返回结果，而声明则没有。

那么 .d.ts 文件在实践中是如何使用的呢？

假设我们有一个 add 函数，分别在两个文件中存储声明和实现：add.d.ts 和 add.js。

现在我们创建一个新文件 index.js，它将实际使用 add 函数：

import { add } from "./x";



const result = add(1, 4);

console.log(result); // 输出：5

请注意，在这个 JS 文件中，add 函数具有类型安全性，因为函数在 add.d.ts 中被标注了类型声明。

替换方案 .ts 文件

我们已经了解了 .d.ts 文件的工作原理以及它们的用途。Matt 之所以认为不需要.d.ts 文件，是因为它也可以放在一个 .ts 文件中直接创建带有类型标注的实现。也就是说，拥有一个包含声明和实现的单个 add.ts 文件，等同于分别定义了 add.d.ts 和 add.js 文件。

这意味着你无需担心将声明文件与其对应的实现文件分开组织。

不过，针对类库，将 .d.ts 文件与编译后的 JavaScript 源代码一起使用，比存储 .ts 文件更高效，因为你真正需要的只是类型声明，以便用户在使用你的库时能够获得类型安全性。

这确实没错，需要强调的是，更推荐自动生成。通过更改 package.json 和 tsconfig.json 文件中的几个设置，从 .ts 文件自动生成 .d.ts 文件：

• tsconfig.json：确保添加 declaration: true，以支持 .d.ts 文件的生成。

{

  "compilerOptions": {

    "declaration": true,

    "target": "ES6",

    "module": "commonjs",

    "outDir": "./dist",

    "strict": true

  },

  "include": ["src/**/*"]

}

• package.json：确保将 types 属性设置为生成的 .d.ts 文件，该文件位于编译后的源代码旁边。

{

  "name": "stop using d.ts",

  "version": "1.0.0",

  "main": "dist/index.js",

  "types": "dist/index.d.ts",

  "scripts": {

    "build": "tsc"

  }

}

结论

.d.ts 文件中可以做到的一切，都可以在 .ts 文件中完成。

在 .ts 文件中使用 declare global {} 语法时，花括号内的内容将被视为全局环境声明，这本质上就是 .d.ts 文件的工作方式。

所以即使不使用.d.ts文件，也可以拥有全局可访问的类型。.ts文件在功能上既可以包含代码实现，又可以包含类型声明，而且还能实现全局的类型声明，从而在开发过程中可以更加方便地管理和使用类型，避免了在.d.ts文件和.ts文件之间进行复杂的协调和组织，提高了开发效率和开发体验。

另外需要注意的是，在大多数项目中，开发者会在 TypeScript 的配置文件（tsconfig.json）中将 skipLibCheck 选项设置为 true。skipLibCheck 的作用是跳过对库文件（包括 .d.ts 文件）的类型检查。当设置为 true 时，TypeScript 编译器不会对这些库文件进行严格的类型检查，从而加快编译速度。但这也会影响项目中自己编写的 .d.ts 文件。这意味着，即使 .d.ts 文件中定义的类型存在错误，TypeScript 编译器也不会报错，从而失去了类型安全性的保障。

而我们直接使用 .ts 文件，就不会有这个问题了，同事手动编写 .d.ts 文件，也会更加安全和高效。

因此，.d.ts 文件确实没有必要编写。在 99% 的情况下，.ts 文件更适合使用，可以改善开发体验，并降低库代码中出现类型错误的可能性。

怎么样？？你同意他的看法么？

前言

Hi 你好，我是东东拿铁，一个正在探索个人IP的后端程序员。

2020年外卖最火热的时候，有一篇文章《外卖骑手，困在系统里》。

作为一个互联网从业人员，我之前从未有机会体会到，当每一个工作都要被时间和算法压榨时，我会是一种怎样的感受。

而最近的一段经历，我感觉也被困在系统里了。

起因

如果你是一个研发人员，免不了要值班、处理线上问题。当然这都很正常，每个系统都有bug或者咨询类的问题。

由于我们面临的客户比较多，加上系统有一些易用性的问题或bug，提出来的问题不少。

公司有一项政策，当客服人员提交工单之后，系统对每一个单子有超时时间，如果超出一定时间你还未提交，罚款50元。

挺奇葩的，谁能保证1个小时就一定能排查出问题呢？

于是就会有一个场景，如果赶上问题多，一下子来5、6个工单，恰巧遇到不容易排查的耽误时间的话，处理后面的工单，都面临着超时的压力。

之前同事们对值班这件事，充满了怨言，大多都会吐槽几个点

我不太爱吐槽，但当工单一下子来的太多的时候，我不由自主的陷入机械的处理问题中，压缩思考的时间，只求不要超时就好。

明明系统有很多问题需要解决、流程也有很多可以优化，可当系统给到我们的压力越来越多时，我们便不去思考，陷入只有吐槽、怨言和避免罚款的状态。

当陷入了系统的支配，只能被动接受，甚至有了一些怨言的时候，我意识到，这样的状态，是有问题的。

被困住的打工人

外卖员为什么不遵守交通规则呢？

外卖小哥为了多赚钱、避免处罚，我之前也很不理解，为什么为了避免处罚，连自己的生命安全都可以置之不顾。

但转念一想，我们虽然不用在马路上奔波，可受到“系统”的压力，可是一点也不比外卖员少。

大家一定有过类似的经历：你骑车或者开车去上班，距离打卡时间所剩无几，你在迟到的边缘疯狂试探，可能多一个红绿灯，你就赶不上了，这时候你会不会狠踩几脚油门、闯一个黄灯，想要更快一点呢？

但随着裁员、降本增效、各类指标的压力越来越大，我们被迫不停的内卷，不断压榨自己，才能满足职场要求越来越严格的“算法”，比如，每半年一次的绩效考核，月度或者季度的OKR、KPI，还有处理不完的线上问题、事故，充斥在我们的脑海里面。

其实我们何尝不是“外卖员”呢？外卖员是为了不被扣钱，我们是为了年终奖、晋升罢了。

所以回过头来看，其实我们早早的就被困在“系统”中了，为了满足系统的要求，我们不得不埋头苦干，甚至加班透支身体，作出很多非常短线思维的事情。

但为什么，我之前从来没有过被困住的感觉，为什么我现在才回过神来，意识到这个问题呢？

我想，大概是越简单的事情，你作出的反应就越快、越激烈。而越复杂、时间越长的事情，你作出的反应就越缓慢，甚至忽略掉。

比如上班即将迟到的你，你会立刻意识到，迟到可能会受到处罚。但是年终评估你的绩效目标时，你或许只有在最后的几个月才会意识到，某某事情没完成，年终奖或许要少几个月而感到着急。

积极主动

最近正好在读《高效能人士的七个习惯》，其中第一个习惯就是积极主动。

书中说到：人性的本质是主动而非被动的，人类不仅能针对特定环境选择回应方式，更能主动创造有利的环境。

我们面对的问题可以分为三类：

• 可直接控制的（问题与自身的行为有关）


• 可间接控制的（问题与他人的行为有关）


• 无法控制的（我们无能为力的问题，例如我们的过去或现实的环境）

对于这三类问题，积极主动的话，应该如何加以解决呢。

可直接控制的问题

针对可直接控制的问题，可以通过培养正确习惯来解决。

从程序员角度来看，线上bug多，可以在开发前进行技术设计，上线前进行代码CR，自动化测试，帮助自己避免低级的问题。

面对处理工单时咨询量特别多的问题，随手整理个文档出来，放到大家都可以看到的地方。

可间接控制的

对于可间接控制的，我们可以通过改进施加影响的方法来解决。

比如流程机制的不合理，你可以通过向上反馈的方式施加影响，提出自己的建议而不是吐槽。

无法控制的

对于无法控制的，我们要做的就是改变面部曲线，以微笑、真诚与平和来接受现实。

虽然反馈问题的人或许能力参差不齐，导致工单量很多，但我们意识到这一点是无法避免的，不如一笑而过，这样才不至于被问题左右。

说在最后

好了，文章到这里就要结束了。

最近由于值班的原因，陷入了一段时间的无效忙碌中，每一天都很累，几乎抽不出时间来思考，所以更新的频率也降下来了。

但还好，及时的意识到问题，把最近的一点思考分享出来，希望我们每个人都不会被“系统”困住。

欢迎你在评论区和我分享，也希望你点赞、评论、收藏，让我知道对你有所收获，这对我来说很重要。也欢迎你加我的wx：Ldhrlhy10，一起交流～

本篇文章是第41篇原创文章，2024目标进度41/100，欢迎有趣的你，关注我。

Typora 是一款广受欢迎的 Markdown 编辑器，以其所见即所得的编辑模式和优雅的界面而闻名，长期以来是许多 Markdown 用户的首选。然而，从 2021 年起，Typora 不再免费，采用一次性付费授权模式。虽然费用不高，但对于轻量使用者或预算有限的用户可能并不友好。

今天来推荐一款开源替代品，一款更加轻量化、注重隐私且完全免费的 Markdown 编辑器，专为 macOS 用户开发。

项目介绍

MarkEdit 是一款轻量级且高效的 Markdown 编辑器，专为 macOS 用户设计，安装包大小不到 3 MB。它以简洁的设计和流畅的性能，成为技术写作、笔记记录、博客创作以及项目文档编辑的理想工具。无论是编写技术文档、撰写博客文章，还是编辑 README 文件，MarkEdit 都能以快速响应和便捷操作帮助用户专注于内容创作。

根据官方介绍，MarkEdit 免费的原因如下:

MarkEdit 是完全免费和开源的，没有任何广告或其他服务。我们之所以发布它，是因为我们喜欢它，我们不期望从中获得任何收入。

功能特性

MarkEdit 的核心功能围绕 Markdown 写作展开，注重实用与高效，以下是其主要特性：

• 实时语法高亮：清晰呈现 Markdown 的结构，让文档层次分明。


• 多种主题：提供不同的配色方案，总有一种适合你。


• 分屏实时预览：支持所见即所得的写作体验，左侧编辑，右侧实时渲染。


• 文件树视图：适合多文件项目管理，方便在项目间快速切换。


• 文档导出：支持将 Markdown 文件导出为 PDF 或 HTML 格式，方便分享和发布。


• CodeMirror 插件支持：通过插件扩展功能，满足更多 Markdown 使用需求。


• ......

MarkEdit 的特点让它能胜任多种写作场合：

• 技术文档：帮助开发者快速记录项目相关文档。


• 博客创作：支持实时预览，让博客排版更直观。


• 个人笔记：轻量且启动迅速，适合日常记录。


• 项目文档：文件管理功能让多文件项目的编辑更加高效。

效果展示

多种主题风格，总有一种适合你：

实时预览，让博客排版更直观：

设置界面，清晰直观：

安装方法

方法 1：安装包下载

找到 MarkEdit 的最新版本安装包下载使用即可，地址：github.com/MarkEdit-ap… 。

方法 2：通过 Homebrew

在终端中运行相关命令即可完成安装。

brew install markedit

注意：MarkEdit 支持 macOS Sonoma 和 macOS Sequoia， 历史兼容版本包括 macOS 12 和 macOS 13。

总结

MarkEdit 是一款专注于 Markdown 写作的 macOS 原生编辑器，以简洁、高效、隐私友好为核心设计理念。无论是日常写作还是处理复杂文档，它都能提供流畅的体验和强大的功能。对于追求高效写作的 macOS 用户来说，MarkEdit 是一个不可多得的优秀工具。

项目地址：github.com/MarkEdit-ap… 。

前言

最近在公司改bug，突然发现上一个前端留下的毛病不少，页面存在各种适配问题，为此甲方爸爸时常提出宝贵意见！

你的页面是不是时常是这样：

侧边栏未收缩时：

收缩后：

这样（缩小挤成一坨）：

又或是这样：

那么废话不多说，今天由我不是程序猿kk为大家讲解一些前端必备知识：适配工作。

流式布局

学会利用相对单位（例如百分比，vh或是vw），而不是只会用px一类固定单位设计布局，前言中提到的收缩后多出一大块空白，就是由于写死了宽度，例如1000px或是89vw，那么当侧边栏进行收缩，右边内容宽度还是只有89个vw，因此我们可以将其更改为100%，这样不论侧边栏是否收缩，内容都会占满屏幕的全部。

.map {

  width: 100%;

  height: 90vh;

  position: relative;

}

rem和第三方插件

什么是rem

rem与em不同，rem会根据html的根节点字体大小进行变换，例如1rem就是一个字体大小那么大，比如根大小font size为12px，那么1rem即12px，大家可以在网上寻找单位换算工具进行换算（从设计稿的px到rem）或是下载相关插件例如gulp-px3rem，这样在不同分辨率，不同缩放比的电脑下都能够轻松应对了。

使用

第三方插件，例如做移动端适配的flexible.js，lib-flexible库，其核心原理就是rem,我们需要做的就是根据不同屏幕计算出不同的fontsize，而页面中元素都是用rem做单位，据此实现了自适应

源码：

;(function(win, lib) {

    var doc = win.document;

    var docEl = doc.documentElement;

    var metaEl = doc.querySelector('meta[name="viewport"]');

    var flexibleEl = doc.querySelector('meta[name="flexible"]');

    var dpr = 0;

    var scale = 0;

    var tid;

    var flexible = lib.flexible || (lib.flexible = {});

    

    if (metaEl) {

        console.warn('将根据已有的meta标签来设置缩放比例');

        var match = metaEl.getAttribute('content').match(/initial-scale=([d.]+)/);

        if (match) {

            scale = parseFloat(match[1]);

            dpr = parseInt(1 / scale);

        }

    } else if (flexibleEl) {

        var content = flexibleEl.getAttribute('content');

        if (content) {

            var initialDpr = content.match(/initial-dpr=([d.]+)/);

            var maximumDpr = content.match(/maximum-dpr=([d.]+)/);

            if (initialDpr) {

                dpr = parseFloat(initialDpr[1]);

                scale = parseFloat((1 / dpr).toFixed(2));    

            }

            if (maximumDpr) {

                dpr = parseFloat(maximumDpr[1]);

                scale = parseFloat((1 / dpr).toFixed(2));    

            }

        }

    }



    if (!dpr && !scale) {

        var isAndroid = win.navigator.appVersion.match(/android/gi);

        var isIPhone = win.navigator.appVersion.match(/iphone/gi);

        var devicePixelRatio = win.devicePixelRatio;

        if (isIPhone) {

            // iOS下，对于2和3的屏，用2倍的方案，其余的用1倍方案

            if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {                

                dpr = 3;

            } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){

                dpr = 2;

            } else {

                dpr = 1;

            }

        } else {

            // 其他设备下，仍旧使用1倍的方案

            dpr = 1;

        }

        scale = 1 / dpr;

    }



    docEl.setAttribute('data-dpr', dpr);

    if (!metaEl) {

        metaEl = doc.createElement('meta');

        metaEl.setAttribute('name', 'viewport');

        metaEl.setAttribute('content', 'initial-scale=' + scale + ', maximum-scale=' + scale + ', minimum-scale=' + scale + ', user-scalable=no');

        if (docEl.firstElementChild) {

            docEl.firstElementChild.appendChild(metaEl);

        } else {

            var wrap = doc.createElement('div');

            wrap.appendChild(metaEl);

            doc.write(wrap.innerHTML);

        }

    }



    function refreshRem(){

        var width = docEl.getBoundingClientRect().width;

        if (width / dpr > 540) {

            width = 540 * dpr;

        }

        var rem = width / 10;

        docEl.style.fontSize = rem + 'px';

        flexible.rem = win.rem = rem;

    }



    win.addEventListener('resize', function() {

        clearTimeout(tid);

        tid = setTimeout(refreshRem, 300);

    }, false);

    win.addEventListener('pageshow', function(e) {

        if (e.persisted) {

            clearTimeout(tid);

            tid = setTimeout(refreshRem, 300);

        }

    }, false);



    if (doc.readyState === 'complete') {

        doc.body.style.fontSize = 12 * dpr + 'px';

    } else {

        doc.addEventListener('DOMContentLoaded', function(e) {

            doc.body.style.fontSize = 12 * dpr + 'px';

        }, false);

    }

    



    refreshRem();



    flexible.dpr = win.dpr = dpr;

    flexible.refreshRem = refreshRem;

    flexible.rem2px = function(d) {

        var val = parseFloat(d) * this.rem;

        if (typeof d === 'string' && d.match(/rem$/)) {

            val += 'px';

        }

        return val;

    }

    flexible.px2rem = function(d) {

        var val = parseFloat(d) / this.rem;

        if (typeof d === 'string' && d.match(/px$/)) {

            val += 'rem';

        }

        return val;

    }



})(window, window['lib'] || (window['lib'] = {}));

大家如果对相关原理感兴趣，可以阅读：flexible.js如何实现rem自适应-前端开发博客

在实际开发中应用场景不同效果不同，因此不能写死px。

在PC端适配我们可以自动转换rem适配方案（postcss-pxtorem、amfe-flexible）,这里以vue3+vite为例子。事实上amfe-flexible是lib-flexible的升级版。

注意： 行内样式px不会转化为rem

npm install postcss postcss-pxtorem --save-dev  // 我试过了反正我报错了，版本太高 大家可以指定5.1.1

npm install postcss-pxtorem@^5.1.1 

npm i amfe-flexible --save

记得在main.js中引入amfe-flexible

import "amfe-flexible"

相关配置

媒体查询

通过查询不同的宽度来执行不同的css代码，最终以达到界面的配置。

在 CSS 中使用 @media 查询来检测屏幕宽度。当屏幕宽度小于 1024px 时，增加 margin-top 以向下移动表格。

.responsive-table {

  transition: margin-top 0.3s; /* 添加过渡效果 */

}



@media (max-width: 1024px) {

  .responsive-table {

    margin-top: 200px; /* 向下移动的距离 */

  }

}

弹性布局

创建一个响应式的卡片布局，当屏幕宽度减小时，卡片会自动换行。

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

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

    <title>Flexbox Example</title>

    <style>

        body {

            display: flex;

            justify-content: center;

            align-items: center;

            flex-wrap: wrap;

            margin: 0;

            height: 100vh;

            background-color: #f0f0f0;

        }



        .card-container {

            display: flex;

            flex-wrap: wrap;

            justify-content: center;

            width: 90%;

        }



        .card {

            background-color: white;

            border: 1px solid #ccc;

            border-radius: 5px;

            padding: 20px;

            margin: 10px;

            flex: 1 1 300px; /* 基于300px，允许增长和收缩 */

            box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);

            transition: transform 0.3s;

        }



        .card:hover {

            transform: translateY(-5px);

        }

    </style>

</head>

<body>

    <div class="card-container">

        <div class="card">Card 1</div>

        <div class="card">Card 2</div>

        <div class="card">Card 3</div>

        <div class="card">Card 4</div>

        <div class="card">Card 5</div>

    </div>

</body>

</html>

小结

还是多提一嘴，应该不会有小伙伴把字体大小的单位也用rem吧？

大家好，我是农村程序员，独立开发者，前端之虎陈随易。

这是我的个人网站：chensuiyi.me，欢迎一起交朋友~

有很多人跟我聊到过这个问题：做独立开发，家人不支持怎么办？。

在我交流沟通下，最终发现，这些人都走进了一个误区：独立开发者 等于 我要辞职全职做独立开发。

请看我对独立开发者的分类：

现在是不是一目了然了。

你可以根据自己当下的情况，特点，去选择做哪一种 独立开发。

我们目前所看到的 全职独立开发，只有极少数人可以做到。

这对于个人的内在要求，包括自律，坚持，执行力，产品力，都有着较高的要求。

同时呢，来自家人的态度和压力，也是 全职独立开发 的重要条件。

不要一开始，啥独立开发的经验都没有，就想做 全职独立开发。

那么当你可以 理性地选择 适合自己当下情况的的独立开发方式后，你会发现，家人还会不支持吗？至少不会那么反对了。

所以这个问题的答案就是这么简单，只要看了我对独立开发的分类，你就明白了。

独立开发，本就是一个人的战斗，不要妄想这家人会支持你，他们最大的支持就是不反对。

我们遇到这样的问题时，不要觉得家人怎么怎么样，自己受到了多大的委屈和不理解一样。

他们的想法，是完全没有问题的。

人是社会动物，必然要考虑当下的生存问题，这是十分合理且正常的。

那么，如果上面的问题解决后，家人还是不支持，怎么办呢？

也很简单啊，自己偷摸摸继续折腾呗，难道一定要得到家人的支持，才能做独立开发吗？

《明朝那些事》 的作者，当年明月，赚了几千万家人才知道呢。

当然，我不是说你，也不是说我自己，可以赚几千万，我们可以定目标，但不能做梦。

总而言之就是说，做独立开发，要做好一个人长期战斗的准备。

因为你很有可能，很多年都无法比较稳定地每个月赚 5000 块钱，独立开发远没有我们想象的那么轻松。

如果你实在没有时间，没有干劲，没有激情做独立开发，那么不如其他方向，说不定能获得更好的回报。

独立开发是一个美好的梦，不稳定，也容易破碎。

那么我为什么一直在坚持做独立开发呢？因为我想让美梦成真。

在制作一个页面时，如何兼容PC端和手机端是一个重要的设计决策。这个决策通常有两个选择：分别制作两个页面，或者只制作一个自适应页面。以下是我选择后者的理由，以及如何实现自适应设计的相关内容。

选择自适应设计的理由

如何实现自适应设计

总结

在制作兼容PC端和手机端的页面时，选择制作一个自适应页面是更为高效和经济的方案。它不仅能提高开发效率和维护成本，还能提供一致的用户体验，增强SEO效果。此外，现代的CSS技术使得实现自适应设计变得更加简单。因此，采用自适应设计是现代Web开发的最佳实践之一。

一款成功的APP不仅仅取决于其功能性，更取决于用户体验，这其中，UI设计又至关重要。优秀的UI设计能够为用户带来直观、愉悦的交互体验，甚至让用户“一见钟情”，从而大大提高产品吸引力。

然而，有很多设计师在追求创新与美观的同时，往往会不经意间“踩雷”，忽略了一些普通用户更在意的问题和痛点。本文，笔者将谈谈UI设计中的常见误区，同时展示了优秀的UI设计例子，还分享一些行业内推荐的设计工具，希望能助你在设计的道路上更加得心应手~

UI设计常见误区

1、过度设计

设计大师 Dieter Rams 说过一句话：“好的设计是尽可能简单的设计。”

不过，说起来容易做起来难。产品经理和设计师总是不自觉地让产品过于复杂，今天想在产品中再添加一个功能，明天想在页面上再增加一个元素。

尤其是新手设计师，总希望通过增加视觉元素、动画效果和复杂的交互来提升用户体验。然而，这种做法往往适得其反，一个简洁、清晰且直观的界面一定比一个装饰过多、功能复杂的界面更能吸引用户。设计师应该专注于APP的核心功能，避免不必要的元素，确保设计美观又实用。

简约风接单APP界面

http://www.mockplus.cn/example/rp/…

2、忽视用户反馈

有时候，设计师可能过于相信自己的设计，忽略了用户的意见和反馈。这种情况下，即使设计再怎么创新或美观，如果不符合用户的实际需求和使用习惯，也难以获得用户的认可。

毕竟，UI设计不是艺术创作，用户反馈是设计迭代过程中的宝贵资源，它可以帮助设计师了解用户的真实体验，了解设计的不足，从而进行针对性的优化改进。

FARFETCH APP界面

http://www.mockplus.cn/example/rp/…

3、色彩搭配不合适

色彩搭配不合适是UI设计中一个常见的误区。有的设计师会自动倾向于选择那些自己喜欢的颜色，而不是基于用户的偏好和产品特征、背景等来选择颜色。有时，颜色的过度使用或不恰当的搭配会分散用户的注意力，甚至造成视觉疲劳。

另外，为了让用户能看清UI设计的各个方面，需要有足够的对比度。这就是为什么黑色文字配上白色背景效果那么好 —— 文字非常清晰，易于理解。

插画风APP界面

http://www.mockplus.cn/example/rp/…

4、忽略可访问性

对一个APP来说，所有用户，无论是有视觉障碍的人还是老年用户，都应该能够轻松地使用APP。设计如果不考虑这些用户群体的需要，会无意中排除一大部分潜在用户。

为了提高APP的可访问性，设计师应该考虑到字体大小、颜色对比度、语音读出功能等，确保所有用户都能舒适地使用。

社交类APP界面

http://www.mockplus.cn/example/rp/…

5、布局空滤不全面

有的产品界面过多，布局考虑不够全面几乎是常常发生的事。布局不合适有很多种情况，比如元素过于密集、排版杂乱、组件没有对齐、文本大小间距不合适等等。这种情况会导致信息展示不清晰或用户操作不便，非常影响用户的使用体验和效率。

一个美观舒适的布局应该合理利用空间，确保信息的层次清晰，充分考虑元素的大小和间距，让界面既清晰又易于操作，用户可以轻松地找到他们关心的内容。

想要避免这一误区的，在设计初期就需要考虑用户的需求和行为模式，不断迭代优化布局设计，找到最佳的解决方案。

加密货币钱包APP界面

http://www.mockplus.cn/example/rp/…

了解了上述UI设计的常见误区后，接下来是选择合适的设计工具来提升设计效率和质量。目前，市面上有很多优秀的UI设计工具，但以下几款因其强大的功能和良好的用户体验受到设计师的广泛推荐，一起来看看！

UI工具推荐

1、摹客 DT

摹客DT（http://www.mockplus.cn/dt）是一款国内很多UI设计师都爱用的工具，它提供了一整套完整的专业矢量编辑功能，丰富的图层样式选项，可以轻松创建高质量的App设计，并且还能在线实时协同，搞定团队资产管理难题不是问题。

主要功能点和亮点：

1）所有功能完全免费（参与它们的小活动还能永久免费使用），包含所有高级功能、导出能力等；

2）颜色、文本样式、图层样式都可以保存为资源，复用到其他设计元素；

3）支持导出SVG、JPG、PNG、webP、PDF格式文件，适配不同使用场景；

4）具有完善的团队协作和项目管理能力，改变传统设计流程，降低成本，提升效率。

**价格：**完全免费

**学习难度：**简单，新手上手无难度

**使用环境：**Web/客户端/Android/iOS

**推荐理由：**摹客DT，是一款更适合中国设计师的UI/UX设计工具。与一些老牌设计工具（Photoshop、XD等），它的学习门槛更低，上手更简单，社区和实时客户支持更迅速友好；作为Web端工具，摹客DT支持多人实时编辑，大大提高了团队设计效率。

推荐评级：⭐⭐⭐⭐⭐

2、Figma

Figma（http://www.figma.com/）是现在最流行的UI设…

主要功能点及亮点：

1）丰富的功能和工具：提供了全面的工具和功能来设计界面，包括矢量图形工具、网格和布局指导等。

2）设计组件和样式库：支持创建可复用的设计组件和样式库，节省时间和工作量。

3）插件生态系统：有丰富的插件生态系统，可以通过插件扩展功能，增加额外的设计工具和集成，以满足特定需求。

**价格：**提供免费版和付费版（12美元/月起）

**学习难度：**对新手相对友好，操作简单。

**使用环境：**Figma是基于Web的平台，通过浏览器即可使用。

推荐理由：

Figma设计功能强大，提供了丰富的插件和集成，还有有一个庞大的社区交流学习，是一款非常适合团队协作的工具。遗憾的是，Figma作为一款国外设计工具，在国内使用还是存在一定的劣势，比如网络访问限制、数据隐私和安全、本地化支持等，所以只能给到四星。

推荐评级：⭐⭐⭐⭐

3、Sketch

Sketch（http://www.sketch.com/）是一款专业的UI/U…

主要功能及亮点：

3）Sketch支持众多插件和第三方资源，使得其生态系统非常丰富，能够更好地满足设计师的需求。

**价格：**标准订阅 $10/月/人（按年付费），$12/月/人（按月付费）

**使用环境：**macOS操作系统

推荐理由：

Sketch被广泛应用于移动应用、网页设计和用户界面设计等领域。它友好的界面、丰富的设计资源使设计师们能够快速创建出符合良好用户体验和视觉效果要求的设计。可惜的是，它只支持macOS系统，限制了部分用户使用。

**推荐评级：**⭐⭐⭐⭐

4、Adobe XD

Adobe XD（helpx.adobe.com/support/xd.…

主要功能及亮点：

1）丰富的设计和布局功能：设计师可以借助这些功能，轻松创建响应式设计，预览在不同设备上的效果，确保设计的一致性和灵活性。

2）丰富的交互动画和过渡效果：可以创建十分流畅的交互体验，用来更好地展示APP或网站的交互逻辑。

3）共享和协作：支持团队协作，用户可以轻松地共享设计文件，协同编辑，以及通过实时协作功能进行设计评审。

**价格：**提供免费试用，提供付费订阅 $9.99/月

**学习难度：**中

**使用环境：**Windows、macOS

**推荐理由：**Adobe XD与Adobe Creative Cloud紧密集成，十分方便同时使用Adobe其他软件的用户。不过有个问题是，Adobe xd已经官宣停止更新，只向老用户提供服务了，如果是之前没有使用Adobe XD的用户，最好选择其他产品。

**推荐评级：**⭐️⭐️⭐️

五、Principle

Principle是一款专门用于UI/UX设计的软件，它的设计理念是想要让设计师能够轻松创建出高质量、富有吸引力的产品界面效果。

主要功能及亮点：

1）高级动画控制：软件支持创建复杂的动画效果，包括过渡、转换和多状态动画。这对于展示复杂的交互过程和动态效果非常有用。

2）实时预览：Principle允许设计师实时预览他们的工作成果，这意味着可以即时查看和测试动画效果，确保设计的交互体验符合预期。

3）组件和重复使用：设计师可以创建可重复使用的组件，这大大提高了工作效率，特别是在处理具有相似元素或布局的多个界面时。

价格：$129

**学习难度：**中

**使用环境：**MacOS

推荐理由：

设计师通过Principle可以快速地制作出具有丰富交互的产品界面设计，并且它能和Sketch进行无缝链接，可以快速导入你在Sketch里已经做好的图，

推荐评级：⭐️⭐️⭐️⭐️

好的UI设计不仅仅是视觉上的享受，更是能让用户能够轻松、愉快地使用APP。避免上述UI设计误区，选择合适的设计工具，可以帮助我们设计出既美观又实用的产品。

希望本文章能为UI设计师/准UI设计师们有所帮助，创作出更多优秀的设计作品~

看到这里的读者朋友有福啦！本人吐血搜集整理，全网最全产品设计学习资料！

只要花1分钟填写**问卷**就能免费领取以下超值礼包：

1、产品经理必读的100本书 包含：产品思维、大厂案例、技能提升、数据分析、项目管理等各类经典书籍，从产品入门到精通一网打尽！ 2、UI/UX设计师必读的115本书 包含：UI/UX设计、平面设计、版式设计、设计心理学、设计思维等各类经典书籍，看完你就是设计大神！ 3、30G互联网人知识礼包 包含：

• 10GPM礼包，产品案例、大咖分享、行业报告等应有尽有


• 10GUI/UE资源，优秀设计案例、资料包、源文件免费领


• 5G运营资料包，超全产品、电商、新媒体、活动等运营技能


• 5G职场/营销资料包，包含产品设计求职面试、营销增长等

4、50G热门流行的AI学习大礼包

包含：AI绘画、AIGC精选课程、AI职场实用教程等

5、30G职场必备技能包

包含：精选PPT模板、免费可商用字体包、各岗位能力模型、Excel学习资料、求职面试、升职加薪、职场写作和沟通等实用资源。

礼包资源持续更新，互联网行业知识一网打尽！礼包领取地址：

docs.qq.com/form/page/D…

前言

后端开发忙，不给你接口？

后端抱怨你在测试过程中，频繁的给脏数据？

后端修个接口很慢没法测试？

有了 mockjs ，这些问题将迎刃而解。不要 998，pnpm i 带回家！

真这么丝滑？

请看我的使用方式：

当后端接口无法满足要求，且不能及时更改时。例如后端返回

{

  "err_no": 0,

  "err_msg": "success",

  "data": [

    {

      "comment_id": "7337487924836287242",

      "user_info": {

        "user_name": "陈陈陈_",

      }

    }

  ],

}

但我此时希望增加一个 user_type 来确定页面的展示。

那我就直接起一个文件：user.js，把刚才的响应 copy 过来，并追加改动

myMock('/api/v1/user', 'post', () => {

  return {

      "err_no": 0,

      "err_msg": "success",

      "data": [

        {

          "comment_id": "7337487924836287242",

          "user_info": {

            "user_name": "陈陈陈_",

            "user_type": "admin",

          }

        }

      ],

  }

});

如此一来，这个请求就被无缝替换为了我们的 mock，可以随便测试了。

如何接入 mockjs

有的同学就要问了，主播主播，你的 mockjs 确实很方便，怎么接入比较好呀。别急，我们一步一步来

1. 安装 mockjs

pnpm i mockjs

如果是使用 ts 的同学，可能需要额外安装 type 类型包：@types/mockjs

2. 新建一个 mock 文件夹，在 mock/index.ts 放入基本路径

// 各种 mock 的文件，视条件而定，我这里有俩文件就引入了俩

import './login/user.js';

import './model/model.js';

并且在你的项目入口 ts 中引入 mock/index.ts

import './mock/index'; // 引入 mock 配置

3. 导出一个 myMock 方法，并追加一个 baseUrl 方便直接联动你的 axios

import { ENV_TEST } from '@/api/config/interceptor';

import Mock from 'mockjs';



export const myMock = (

  path: string,

  method: 'get' | 'post',

  callback: (options: any) => any

) => {

  Mock.mock(`${ENV_TEST}${path}`, method, callback);

};

如此一来，你就可以在 mock 文件夹下去搞了，比如：

我想新增一个服务模块的各类接口的 mock，那么我就新增一个 service 文件夹，在其下增加一个 index.ts，并对对应路径进行 mock

myMock('/api/v1/service', 'get', () => {

  return {

    code: 0,

    msg: 'hello service',

    data: null,

  };

});

另外，别忘了在 mock/index.ts 引入文件

不显示在 network 中？

需要说明的是，这样走 mock 是不会触发真正的请求的，相当于 xhr 直接被 mock 拦截了下来并给了你返回值。所以你无法在 network 中看到你的请求。

这是个痛点，目前比较好的解决方案还是起一个单独的服务来 mock。但这样也就意味着，需要另起一个项目来单独做 mock，太不优雅了。

有没有什么办法，既可以走上述简单的mock，又可以在需要的时候起一个服务来查看 network，并且不需要额外维护两套配置呢？

有的兄弟，有的。

import express from 'express';

import bodyParser from 'body-parser';

import Mock from 'mockjs';

import './login/user.js';

import './model/model.js';

import { ENV_TEST } from './utils/index.js';



const app = express();

const port = 3010;



// 使用中间件处理请求体和CORS

app.use(bodyParser.json());



// 设置CORS头部

app.use(( _ , res, next) => {

  res.header('Access-Control-Allow-Origin', '*');

  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');

  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  next();

});



// 设置Mock路由的函数

const setupMockRoutes = () => {

  const mockApis = Mock._mocked || {};



  // 遍历每个Mock API，并生成对应的路由

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

    const { rurl, rtype, template } = mockApis[key];

    const route = rurl.replace(ENV_TEST, ''); // 去掉环境前缀



    // 根据请求类型（GET, POST, 等）设置路由

    app[rtype.toLowerCase()](route, (req, res) => {

      const data =

        typeof template === 'function' ? template(req.body || {}) : template;

      res.json(Mock.mock(data)); // 返回模拟数据

    });

  });

};



// 设置Mock API路由

setupMockRoutes();



// 启动服务器

app.listen(port, () => {

  process.env.NODE_ENV = 'mock'; // 设置环境变量

  console.log(`Mock 服务已启动，访问地址: http://localhost:${port}`);

});

直接在 mock 文件夹下追加这个启动文件，当你需要看 network 的时候，将环境切换为 mock 环境即可。本质是利用了 Mock._mocked 可以拿到所有注册项，并用 express 起了一个后端服务响应这些注册项来实现的。

在拥有了这个能力的基础上，我们就可以调整我们的命令

  "scripts": {

    "dev": "cross-env NODE_ENV=test vite",

    "mock": "cross-env NODE_ENV=mock vite & node ./src/mock/app.js"

  },

顺便贴一下我的 env 配置：

export const ENV_TEST = 'https://api-ai.com/fuxi';

export const ENV_MOCK = 'http://localhost:3010/';



let baseURL: string = ENV_TEST;



console.log('目前环境为：' + process.env.NODE_ENV);

switch (process.env.NODE_ENV) {

  case 'mock':

    baseURL = ENV_MOCK;

    break;

  case 'test':

    baseURL = ENV_TEST;

    break;

  case 'production':

    break;

  default:

    baseURL = ENV_TEST;

    break;

}



export { baseURL };

这样一来，如果你需要看 network ，就 pnpm mock，如果不需要，就直接 pnpm dev，完全不需要其他心智负担。

三个字：

参数相关

具体的 api 可查阅：github.com/nuysoft/Moc… 相关的文章也非常多，就不展开说明了。

如果这篇文章对你有帮助，不妨点个赞吧~

作者：imoo
来源：juejin.cn/post/7460091261762125865

前言

• 常网IT源码上线啦！


• 本篇录入吊打面试官专栏，希望能祝君拿下Offer一臂之力，各位看官感兴趣可移步🚶。


• 有人说面试造火箭，进去拧螺丝；其实个人觉得问的问题是项目中涉及的点 || 热门的技术栈都是很好的面试体验，不要是旁门左道冷门的知识，实际上并不会用到的。


• 接下来想分享一些自己在项目中遇到的技术选型以及问题场景。

你生命的前半辈子或许属于别人，活在别人的认为里。那把后半辈子还给你自己，去追随你内在的声音。

一、前言

之前在讨论设计模式、算法的时候，一个后端组长冷嘲热讽的说：前端哪有什么设计模式、算法，就好像只有后端语言有一样，至今还记得那不屑的眼神。

今天想起来，就随便列几个，给这位眼里前端无设计模式的人，睁眼看世界。

二、观察者模式 (Observer Pattern)

观察者模式的核心是当数据发生变化时，自动通知并更新相关的视图。在 Vue 中，这通过其响应式系统实现。

Vue 2.x：Object.defineProperty

在 Vue 2.x 中，响应式系统是通过 Object.defineProperty 实现的。每当访问某个对象的属性时，getter 会被触发；当设置属性时，setter 会触发，从而实现数据更新时视图的重新渲染。

源码（简化版）：

function defineReactive(obj, key, val) {

  // 创建一个 dep 实例，用于收集依赖

  const dep = new Dep();



  Object.defineProperty(obj, key, {

    get() {

      // 当访问属性时，触发 getter，并把当前 watcher 依赖收集到 dep 中

      if (Dep.target) {

        dep.addDep(Dep.target);

      }

      return val;

    },

    set(newVal) {

      if (newVal !== val) {

        val = newVal;

        dep.notify(); // 数据更新时，通知所有依赖重新渲染

      }

    }

  });

}

• Dep 类：它管理依赖，addDep 用于添加依赖，notify 用于通知所有依赖更新。

class Dep {

  constructor() {

    this.deps = [];

  }



  addDep(dep) {

    this.deps.push(dep);

  }



  notify() {

    this.deps.forEach(dep => dep.update());

  }

}

• 依赖收集：当 Vue 组件渲染时，会创建一个 watcher 对象，表示一个视图的更新需求。当视图渲染过程中访问数据时，getter 会触发，并将 watcher 添加到 dep 的依赖列表中。

Vue 3.x：Proxy

Vue 3.x 使用了 Proxy 来替代 Object.defineProperty，从而实现了更高效的响应式机制，支持深度代理。

源码（简化版）：

function reactive(target) {

  const handler = {

    get(target, key) {

      // 依赖收集：当访问某个属性时，触发 getter，收集依赖

      track(target, key);

      return target[key];

    },

    set(target, key, value) {

      // 数据更新时，通知相关的视图更新

      target[key] = value;

      trigger(target, key);

      return true;

    }

  };



  return new Proxy(target, handler);

}

• track：收集依赖，确保只有相关组件更新。


• trigger：当数据发生变化时，通知所有依赖重新渲染。

三、发布/订阅模式 (Publish/Subscribe Pattern)

发布/订阅模式通过中央事件总线（Event Bus）实现不同组件间的解耦，Vue 2.x 中，组件间的通信就是基于这种模式实现的。

Vue 2.x：事件总线（Event Bus）

事件总线就是一个中央的事件处理器，Vue 实例可以充当事件总线，用来处理不同组件之间的消息传递。

// 创建一个 Vue 实例作为事件总线

const EventBus = new Vue();



// 组件 A 发布事件

EventBus.$emit('message', 'Hello from A');



// 组件 B 订阅事件

EventBus.$on('message', (msg) => {

  console.log(msg); // 输出 'Hello from A'

});

• $emit：用于发布事件。


• $on：用于订阅事件。


• $off：用于取消订阅事件。

四、工厂模式 (Factory Pattern)

工厂模式通过一个函数生成对象或实例，Vue 的组件化机制和动态组件加载就是通过工厂模式来实现的。

Vue 的 render 函数和 functional 组件支持动态生成组件实例。例如，functional 组件本质上是一个工厂函数，通过给定的 props 返回一个 VNode。

Vue.component('dynamic-component', {

  functional: true,

  render(h, context) {

    // 工厂模式：根据传入的 props 创建不同的 VNode

    return h(context.props.type);

  }

});

• functional 组件：它没有实例，所有的逻辑都是在 render 函数中处理，返回的 VNode 就是组件的“产物”。

五、单例模式 (Singleton Pattern)

单例模式确保某个类只有一个实例，Vue 实例就是全局唯一的。

在 Vue 中，全局的 Vue 构造函数本身就是一个单例对象，通常只会创建一个 Vue 实例，用于管理应用的生命周期和全局配置。

const app = new Vue({

  data: {

    message: 'Hello, Vue!'

  }

});

• 单例保证：整个应用只有一个 Vue 实例，所有全局的配置（如 Vue.config）都是共享的。

六、模板方法模式 (Template Method Pattern)

模板方法模式定义了一个操作中的算法框架，而将一些步骤延迟到子类中。Vue 的生命周期钩子就是一个模板方法模式的实现。

Vue 定义了一系列生命周期钩子（如 created、mounted、updated 等），它们实现了组件从创建到销毁的完整过程。开发者可以在这些钩子中插入自定义逻辑。

Vue.component('my-component', {

  data() {

    return {

      message: 'Hello, 泽!'

    };

  },

  created() {

    console.log('Component created');

  },

  mounted() {

    console.log('Component mounted');

  },

  template: '<div>{{ message }}</div>'

});

Vue 组件的生命周期钩子实现了模板方法模式的核心思想，开发者可以根据需要重写生命周期钩子，而 Vue 保证生命周期的流程和框架。

七、策略模式 (Strategy Pattern)

策略模式通过定义一系列算法，将它们封装起来，使它们可以相互替换。Vue 的 计算属性（computed） 和 方法（methods） 可以看作是策略模式的应用。

计算属性允许我们定义动态的属性，其值是基于其他属性的计算结果。Vue 会根据依赖关系缓存计算结果，只有在依赖的属性发生变化时，计算属性才会重新计算。

new Vue({

  data() {

    return {

      num1: 10,

      num2: 20

    };

  },

  computed: {

    sum() {

      return this.num1 + this.num2;

    }

  }

});

八、装饰器模式 (Decorator Pattern)

装饰器模式允许动态地给对象添加功能，而无需改变其结构。在 Vue 中，指令就是一种装饰器模式的应用，它通过指令来动态地改变元素的行为。

<div v-bind:class="className"></div>

<div v-if="isVisible">谁的疯太谍</div>

这些指令动态地修改 DOM 元素的行为，类似于装饰器在不修改对象结构的情况下，动态地增强其功能。

九、代理模式 (Proxy Pattern)

代理模式通过创建一个代理对象来控制对目标对象的访问。在 Vue 3.x 中，响应式系统就是通过 Proxy 来代理对象的访问。

vue3

const state = reactive({

  count: 0

});



state.count++; // 会触发依赖更新

reactive：使用 Proxy 对对象进行代理，当对象的属性被访问或修改时，都会触发代理器的 get 和 set 操作。

function reactive(target) {

  const handler = {

    get(target, key) {

      // 依赖收集：当访问某个属性时，触发 getter，收集依赖

      track(target, key);

      return target[key];

    },

    set(target, key, value) {

      // 数据更新时，触发依赖更新

      target[key] = value;

      trigger(target, key);

      return true;

    }

  };



  return new Proxy(target, handler);

}

• track：当读取目标对象的属性时，收集依赖，这通常涉及到将当前的 watcher 加入到依赖列表中。


• trigger：当对象的属性发生改变时，通知所有相关的依赖（如组件）更新。

这个 Proxy 机制使得 Vue 可以动态地观察和更新对象的变化，比 Object.defineProperty 更具灵活性。

十、适配器模式 (Adapter Pattern)

适配器模式用于将一个类的接口转换成客户端期望的另一个接口，使得原本不兼容的接口可以一起工作。Vue 的插槽（Slots）和组件的跨平台支持某种程度上借用了适配器模式的思想。

Vue 插槽机制

Vue 的插槽机制是通过提供一个适配层，将父组件传入的内容插入到子组件的指定位置。开发者可以使用具名插槽、作用域插槽等方式，实现灵活的插槽传递。

<template>

  <child-component>

    <template #header>

      <h1>This is the header</h1>

    </template>

    <p>This is the default content</p>

  </child-component>

</template>

父组件通过 #header 插槽插入了一个标题内容，而 child-component 会将其插入到适当的位置。这里，插槽充当了一个适配器，允许父组件插入的内容与子组件的内容结构灵活匹配。

十全十美

至此撒花~

后记

我相信技术不分界，不深入了解，就不要轻易断言。

一个圆，有了一个缺口，不知道的东西就更多了。

但是没有缺口，不知道的东西就少了。

这也就是为什么，知道得越多，不知道的就越多。

谢谢！

最后，祝君能拿下满意的offer。

我是Dignity_呱，来交个朋友呀，有朋自远方来，不亦乐乎呀！深夜末班车

👍 如果对您有帮助，您的点赞是我前进的润滑剂。

以往推荐

小小导出，我大前端足矣！

靓仔，说一下keep-alive缓存组件后怎么更新及原理？

面试官问我watch和computed的区别以及选择？

面试官问我new Vue阶段做了什么？

前端仔，快把dist部署到Nginx上

多图详解，一次性啃懂原型链（上万字）

Vue-Cli3搭建组件库

Vue实现动态路由（和面试官吹项目亮点）

项目中你不知道的Axios骚操作（手写核心原理、兼容性）

VuePress搭建项目组件文档

原文链接

juejin.cn/post/744421…

作为一名后端开发，我们经常需要使用终端工具来管理Linux服务器。最近发现一款比Xshell更好用终端工具XPipe，能支持SSH、Docker、K8S等多种环境，还具有强大的文件管理工具，分享给大家！

XPipe简介

XPipe是一款全新的终端管理工具，具有强大的文件管理功能，目前在Github上已有4.8k+Star。它可以基于你本地安装的命令行工具（例如PowerShell）来执行远程命令，反应速度非常快。如果你有使用 ssh、docker、kubectl 等命令行工具来管理服务器的需求，使用它就可以了。

XPipe具有如下特性：

• 连接中心：能轻松实现所有类型的远程连接，支持SSH、Docker、Podman、Kubernetes、Powershell等环境。


• 强大的文件管理功能：具有对远程系统专门优化的文件管理功能。


• 多种命令行环境支持：包括bash、zsh、cmd、PowerShell等。


• 多功能脚本系统：可以方便地管理可重用脚本。


• 密码保险箱：所有远程连接账户均完全存储于您本地系统中的一个加密安全的存储库中。

下面是XPipe使用过程中的截图，界面还是挺炫酷的！

这或许是一个对你有用的开源项目，mall项目是一套基于 SpringBoot3 + Vue 的电商系统（Github标星60K），后端支持多模块和2024最新微服务架构 ，采用Docker和K8S部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能！

• Boot项目：github.com/macrozheng/…


• Cloud项目：github.com/macrozheng/…


• 教程网站：http://www.macrozheng.com

项目演示：

使用

• 首先去XPipe的Release页面下载它的安装包，我这里下载的是Portable版本，解压即可使用，地址：github.com/xpipe-io/xp…

• 下载完成后进行解压，解压后双击xpiped.exe即可使用；

• 这里我们先进行一些设置，将语言设置成中文，然后设置下主题，个人比较喜欢黑色主题；

• 接下来新建一个SSH连接，输入服务器地址后，选择添加预定义身份；

• 这个预定义身份相当于一个可重用的Linux访问账户；

• 然后输入连接名称，点击完成即可创建连接；

• 我们可以发现XPipe能自动发现服务器器上的Docker环境并创建连接选项，如果你安装了K8S环境的话，也是可以发现到的；

• 然后我们单击下Linux-local这个连接，就可以通过本地命令行工具来管理Linux服务器了；

• 如果你想连接到某个Docker容器的话，直接点击对应容器即可连接，这里以mysql为例；

• 选中左侧远程服务器，点击右侧的文件浏览器按钮可以直接管理远程服务器上的文件，非常方便；

• 在所有脚本功能中，可以存储我们的可重用脚本；

• 在所有身份中存储着我们的账号密码，之前创建的Linux root账户在这里可以进行修改。

总结

今天给大家分享了一款好用的终端工具XPipe，界面炫酷功能强大，它的文件管理功能确实惊艳到我了。而且它可以用本地命令行工具来执行SSH命令，对比一些套壳的跨平台终端工具，反应速度还是非常快的！

项目地址

github.com/xpipe-io/xp…

生娃是人生很重要的事，值得花时间思考。我断断续续想了几年，没想明白，最近看 B 站半佛老师对哪吒 2 的影评，理解了什么情况下可以生娃，把感受分享给大家。

什么时候可以给孩子无条件的、不抱任何期待的爱，什么时候就可以生娃了。

半佛老师在影评中表示非常羡慕哪吒有那样的父母，因为哪吒的父母给哪吒无条件的、不抱任何期待的爱，而半佛老师的童年比较悲惨，让他有点羡慕嫉妒恨。为此半佛特意查了导演饺子的家庭，希望饺子是因为缺爱才把哪吒父母写的那么好，结果发现饺子就是哪吒本吒，他彻底破防了。

过年回家免不了和父母共处几天，我也几度破防，好几次想直接回出租屋。也被催生，丈母娘也催。

之前对生娃的看法，我觉得生娃太费钱了，而我没钱，就算我有钱，我也不想把钱花在娃上面，我想花在自己身上，多体验人生。

其次我自己这辈子都没活明白，也挺痛苦，何必生个娃来这悲惨世间走一遭？所以我不生娃。

但这次我有新的想法，是否生娃，应取决于我是否做好了为人父母的准备，即是否可以给孩子无条件的、不抱任何期待的爱。这决定孩子一辈子是否幸福。

两个关键词，无条件、不抱期待。

无条件

考试考得好，父母就爱，考得不好就不爱；听话就爱，不听话就不爱；不知道你们怎样，我小时候是这样的。

这让我没有安全感，下意识会做些讨好父母的行为，来获得父母的 “ 爱 ”。

当我成年的时候，我妈发现这招不管用了，我不需要他们的爱，我需要钱，因为钱能给我安全感。

所以我大学去食堂打工，每天中午和晚上早点下课过去，结果一个月才 300 块钱包两顿饭。

不抱期待

期待这个东西，在教育中尤为突出，否则不会也有那么多鸡娃的父母。

父母对孩子的期待，让孩子有非常强烈的愧疚。我辛辛苦苦把你从农村带到城市，你就考这么几分？我辛辛苦苦把你拉扯大，你就这么对我？

在这种环境下，我成为了一个逆子，六亲不认，自动屏蔽亲情。我不接受他们的爱，我也不给他们爱。

大学打工的 300 块不能养活我，每年还要交学费，我一想到学费是父母出的，他们又会以此要挟，我辛辛苦苦赚钱供你上大学，结果你就这样？

所以只读了半年大学，我退学了，自己出去找工作，我必须在经济上独立，必须逃离这个家。

别人说家是港湾，外面受伤了家是永远的依靠，对我来说家就是伤害。

其实我这样还算好的，至少活下来了，还有更多孩子，承受不了这种愧疚，选择了自杀，他们要把愧疚，加倍偿还给父母。

我身边就有这样的案例，跳楼了，他父母不知道为什么说了两句，孩子就直接从阳台上跳下去了。

我可太懂了，我也想过自杀，一来是当时家里装了防盗窗，我有点胖钻不过去；然后换成了撞墙，头上撞了几个包有点疼，基因让我停下了；我还尝试过离家出走，也没走成。

但我也在脑海中无数次幻想，要是我死了，我爸妈有多愧疚，这就是我自杀的目的。

我写的和想的有点黑暗，有人说什么爸妈把你辛辛苦苦拉扯大，不容易什么的。

但是我不需要，我没求着来这个世上。

所以我对自己生娃，非常谨慎，我不希望他的童年会想自杀，我不希望他成年后和父母几乎断绝关系，我希望他要来就过的幸福点，这取决我能否会给他无条件的、没有期待的爱。

愿各位都是好父母，愿世上孩子都幸福，以上是我的思考，共勉。

相信很多人和我一样，好奇无虚拟DOM版的Vue为什么叫Vue Vapor。之前看过一个很新颖的观点：Vue1时代就没有虚拟DOM，而那个时代恰好处于前端界的第一次工业革命，也就是以声明式代替命令式的写法。所以无虚拟DOM版Vue让人感觉梦回Vue1，于是就采取了Vapor这个名字。

Vapor是蒸汽的意思，第一次工业革命开创了以机器代替手工劳动的时代，该革命以蒸汽机作为动力机被广泛使用为标志。

不过这个说法并非来自官方，虽然乍一听还挺有道理的，但总感觉官方并不一定是这么想的。事实也的确如此，在官方的Vue Conf中，Vue Vapor的作者出面说明了Vapor这个名字的含义：

由于无虚拟DOM的特性，纯Vapor模式下可以去掉很多代码，比如VDom Diff。所以Vue Vapor的包体积可以做的更加的轻量化，像水蒸气一样轻。

（前面那段话是官方说的，这段话是我说的）当然不是说Vapor模式就不需要diff算法了，我看过同为无虚拟DOM框架的Svelte和Solid源码，无虚拟DOM只是不需要vDom间的Diff算法了，列表之间还是需要diff的。毕竟再怎么编译，你从后端获取到的数组，编译器也不可能预测得到。

那具体能轻量多少呢？官方给出的数据是比虚拟DOM版Vue小33.6%：

Vapor的名字除了想表示轻量化之外还有一个另外一个原因，那就是Solid。可能有人会说这关Solid什么事啊？实际上Vapor的灵感正是来自于Solid（尤雨溪亲口承认）而Solid代表固体：

为了跟Solid有个趣味联动，那无虚拟DOM就是气体好了：

以上就是Vue Vapor作者告诉大家为什么叫Vapor的两大原因。

性能

之前都说虚拟DOM是为了性能，怎么现在又反向宣传了？无虚拟DOM怎么又逆流而上成为了性能的标杆了呢？这个话题我们留到下一篇文章去讲，本篇文章我们只看数据：

从左到右依次为：

• 原生JS：1.01


• Solid：1.09


• Svelte：1.11


• 无虚拟DOM版Vue：1.24


• 虚拟DOM版Vue：1.32


• React：1.55

数字越小代表性能越高，但无论再怎么高都不可能高的过手动优化过的原生JS，毕竟无论什么框架最终打包编译出来的还是JS。不过框架的性能其实已经挺接近原生的了，尤其是以无虚拟DOM著称的Solid和Svelte。但无虚拟DOM版Vue和虚拟DOM版Vue之间并没有拉开什么很大的差距，1.24和1.32这两个数字证明了其实二者的性能差距并不明显，这又是怎么一回事呢？

一个原因是Vue3本来就做了许多编译优化，包括但不限于静态提升、大段静态片段将采用innerHTML渲染、编译时打标记以帮助虚拟DOM走捷径等… 由于本来的性能就已经不错了，所以可提升的空间自然也没多少。

看完上述原因肯定有人会说：可提升的空间没多少可以理解，那为什么还比同为无虚拟DOM的Solid和Svelte差那么多？如果Vapor和Solid性能差不多的话，那可提升空间小倒是说得过去。但要是像现在这样差的还挺多的话，那这个理由是不是就有点站不住脚了？之所以会出现这样的情况是因为Vue Vapor的作者在性能优化和快速实现之间选择了后者，毕竟尤雨溪第一次公布要开始做无虚拟DOM版Vue的时间是在2020年：

而如今已经是2025年了。也就是说如果一个大一新生第一次满心欢喜的听到无虚拟DOM版Vue的消息后，那么他现在大概率已经开始毕业工作了都没能等到无虚拟DOM版Vue的发布。这个时间拖的有点太长了，甚至从Vue2到Vue3都没用这么久。

所以现在的首要目标是先实现出来一版能用的，后面再慢慢进行优化。我们工作不也是这样么？先优先把功能做出来，优化的事以后再说。那么具体该怎么优化呢：

现在的很多渲染逻辑继承自原版Vue3，但无虚拟DOM版Vue可以采用更优的渲染逻辑。而且现在的Vapor是跟着原版Vue的测试集来做的，这也是为了实现和原版Vue一样的行为。但这可能并不是最优解，之后会慢慢去掉一些不必要的功能，尤其是对性能产生较大影响的功能。

往期精彩文章：

《尤雨溪：从Vue1到Vue3.6》

来源 Netflix Removed React?

Netflix 删除了 React

"Netflix 删除了 React,网站加载时间减少了 50%!"

这条爆炸性新闻在推特炸开了锅。这不禁让人想起半年前"微软应该禁止所有新项目使用 React" 的新闻 - 两大科技巨头相继 "抛弃" React,难道这预示着什么?

"React 心智负担重、性能差、bundle 体积大...". 一时间，各种唱衰 React 的声音此起彼伏。有人甚至信誓旦旦地表示:"只要像 Netflix 一样干掉 React,你的网站性能立马提升 50%!"

这条发布于 2024 年 10 月 27 日的推文有着惊人的 150 万浏览量。但是，这大概率是 AI 生成的假新闻。
事实上，我们去 Netflix 的官网打开 react-devtools，发现他们依然在使用 React 构建他们的网站。

Netflix 的真实案例

这篇 AI 生成的假新闻灵感来自 2017 年 Netflix 工程师在 hack news 上发布的一篇文章 - Netflix: Removing client-side React.js improved performance by 50%

他直接移除了这篇文章最重要的部分 - client-side React.js, 也就是客户端的 React.js 代码。

实际的情况是，Netflix 团队在 2017 年的时候在使用 React 构建他们的 landing page。

为什么在一个简单的 landing page 上要使用 React 呢？因为在 landing page 上

• Netflix 需要处理大量的 AB 测试


• 支持近 200 个国家的本地化


• 根据用户设备、地理位置等因素动态调整内容


• 需要服用现有的 React 组件