抓包工具使用指南

序章

Fiddler 是一款功能强大的抓包工具，能够截获、重发、编辑和转存网络传输中的数据包，同时也常用于网络安全检测。它的功能丰富，但在学习过程中可能会遇到一些隐藏的小功能，容易遗忘。因此，本文总结了 Fiddler 的常用功能，并结合 SniffMaster 抓包大师的特点，帮助大家更好地掌握抓包工具的使用。

1. Fiddler 抓包简介

Fiddler 通过改写 HTTP 代理来监控和截取数据包。当 Fiddler 启动时，它会自动设置浏览器的代理，关闭时则会还原代理设置，非常方便。

1.1 字段说明

Fiddler 抓取的数据包会显示在列表中，以下是各字段的含义：

1.2 Statistics 请求性能数据分析

点击任意请求，可以在右侧查看该请求的性能数据和分析结果。

1.3 Inspectors 查看数据内容

Inspectors 用于查看会话的请求和响应内容，上半部分显示请求内容，下半部分显示响应内容。

1.4 AutoResponder 拦截指定请求

AutoResponder 允许拦截符合特定规则的请求，并返回本地资源或 Fiddler 资源，从而替代服务器响应。例如，可以将关键字 "baidu" 与本地图片绑定，访问百度时会被劫持并显示该图片。

1.5 Composer 自定义请求发送

Composer 允许自定义请求并发送到服务器。可以手动创建新请求，或从会话表中拖拽现有请求进行修改。

1.6 Filters 请求过滤规则

Filters 用于过滤请求，避免无关请求干扰。常用的过滤条件包括 Zone（内网或互联网）和 Host（指定域名）。

1.7 Timeline 请求响应时间

Timeline 显示指定内容从服务器传输到客户端的时间，帮助分析请求的响应速度。

2. Fiddler 设置解密 HTTPS 数据

Fiddler 可以通过伪造 CA 证书来解密 HTTPS 数据包。具体步骤如下：

3. 抓取移动端数据包

3.1 设置代理

3.2 安装证书

3.3 抓取数据包

配置完成后，手机访问应用时，Fiddler 会截取到数据包。

4. Fiddler 内置命令与断点

Fiddler 提供了命令行功能，方便快速操作。常用命令包括：

断点功能

Fiddler 的断点功能可以截获请求并暂停发送，方便修改请求内容。常用断点命令包括：

• bpafter：中断包含指定字符串的请求。


• bpu：中断响应。


• bps：中断指定状态码的请求。


• bpv：中断指定 HTTP 方法的请求。

5. SniffMaster 抓包大师

SniffMaster 是一款跨平台抓包工具，支持 Android、iOS 和 PC 端抓包。与 Fiddler 相比，SniffMaster 具有以下优势：

• 自动生成证书：无需手动配置 HTTPS 解密。


• 多设备支持：支持同时抓取多个设备的数据包。


• 智能过滤：按协议、域名等条件快速筛选数据。


• 可视化界面：提供更直观的数据分析和展示。

5.1 SniffMaster 使用场景

• 移动端抓包：支持 Android 和 iOS 设备，自动配置代理和证书。


• HTTPS 解密：内置 HTTPS 解密功能，无需手动安装证书。


• 多平台支持：支持 Windows、macOS 和 Linux 系统。

总结

Fiddler 和 SniffMaster 都是强大的抓包工具，适用于不同的场景。Fiddler 适合需要深度定制和高级功能的用户，而 SniffMaster 则更适合新手和需要快速抓包的用户。无论是开发调试还是网络安全检测，这两款工具都能提供极大的帮助。

什么是惰性函数？

先来看个例子

function addEvent(el, type, handler) {

  if (window.addEventListener) {

    el.addEventListener(type, handler, false);

  } else {

    el.attachEvent('on' + type, handler);

  }

}

上面这段代码中，每次调用 addEvent 都会进行一遍判断。实际上，我们并不需要每次都进行判断，只需要执行一次就够了，当然，我们也可以存个全局的flag来记录，但是，有更好的办法了

function addEvent(el, type, handler) {

  if (window.addEventListener) {

    addEvent = function(el, type, handler) {

      el.addEventListener(type, handler, false);

    }

  } else {

    addEvent = function(el, type, handler) {

      el.attachEvent('on' + type, handler);

    }

  }

  return addEvent(el, type, handler); // 调用新的函数

}

这就是惰性函数：第一次执行时会根据条件覆盖自身，后续调用直接执行更新后的逻辑。

惰性函数的实现方式

惰性函数一般情况下有两种实现方式

在函数内部重写自身

这种实现方式就是上面我们介绍的那样

function foo() {

  console.log('初始化...');

  foo = function() {

    console.log('后续逻辑');

  }

}

大多数情况下，这种实现方式都可以覆盖

用函数表达式赋值

const foo = (function() {

  if (someCondition) {

    return function() { console.log('A'); }

  } else {

    return function() { console.log('B'); }

  }

})();

这种情况适用于模块或者立即执行的情况，其实就是用闭包做了个封装

惰性函数的应用场景

兼容性判断

我们在做适配的时候，很多时候需要进行浏览器特性的判断，比如之前提到的事件绑定

性能优化

其实惰性函数说起来很像单例，他的原理就是只执行一次，那么如果想要避免一些重复操作，尤其是重复初始化，就可以想一下是不是可以用惰性函数来处理，比如Canvas渲染引擎，加载某些外部依赖、判断登录状态等等

注意事项

一句话总结：能判断一次就不要判断两次，惰性函数让你的代码更聪明

Electron 作为将 Web 技术带入桌面应用领域的先驱框架，让无数开发者能够使用熟悉的 HTML、CSS 和 JavaScript 构建跨平台应用。然而，随着应用规模的扩大，Electron 应用的性能问题逐渐显现——内存占用高、启动速度慢、安装包体积庞大，这些都成为了用户体验的绊脚石。不过，现在有了 PakePlus，这些烦恼都将迎刃而解。

PakePlus官网文档：PakePlus

PakePlus开源地址：github.com/Sjj1024/Pak…

首先要轻

以一款基于 Electron 的文档编辑应用为例，在使用 PakePlus 优化前，安装包大小达 200MB，启动时间超过 10 秒。但是使用PakePlus重新打包之后，安装包大小控制在5M左右，缩小了将近40倍！启动时间也做到了2秒以内！这就是PakePLus的魅力所在。

开发者反馈："迁移过程出乎意料的顺利，大部分代码无需修改，性能提升却立竿见影。"

其次都是其次

• 🚀 基于 Rust Tauri，PakePlus 比基于 JS 的框架更轻量、更快。


• 📦 内置丰富功能包——支持快捷方式、沉浸式窗口、极简自定义。


• 👻 PakePlus 只是一个极简的软件，用 Tauri 替代旧的打包方式，支持跨平台桌面，将很快支持手机端。


• 🤗 PakePlus 易于操作使用，只需一个 GitHub Token，即可获得桌面应用。


• 🌹 不需要在本地安装任何复杂的依赖环境，使用 Github Action 云端自动打包。


• 🧑‍🤝‍🧑 支持国际化，对全球用户都非常友好，并且会自动跟随你的电脑系统语言。


• 💡 支持自定义 js 注入。你可以编写自己的 js 代码注入到页面中。


• 🎨 ui 界面更美观更友好对新手更实用，使用更舒适，支持中文名称打包。


• 📡 支持网页端直接使用，但是客户端功能更强大，更推荐客户端。


• 🔐 数据安全，你的 token 仅保存在你本地，不会上传服务器，你的项目也都在你自己的 git 中安全存储。


• 🍀 支持静态文件打包，将 Vue/React 等项目编译后的 dist 目录或者 index.html 丢进来即可成为客户端，何必是网站。


• 🐞 支持 debug 调试模式，无论是预览阶段还是发布阶段，都可以找到 bug 并消灭 bug

使用场景

你有一个网站，想把它立刻变成跨平台桌面应用和手机APP，立刻高大尚。

你有一个 Vue/React 等项目，不想购买服务器，想把它打包成桌面应用。

你的 Cocos 游戏是不是想要跨平台客户端运行？完全没有问题。

你的 Unity 项目是不是想要跨平台打包为客户端？也完全没有问题。

隐藏你的网站地址，不被随意传播和使用，防止爬虫程序获取你的网站内容。

公司内网平台，不想让别人知道你的网站地址，只允许通过你的客户端访问。

想把某个网站变成自己的客户端，实现自定义功能，比如注入 js 实现自动化操作。

网站广告太多？想把它隐藏起来，用无所不能的 js 来屏蔽它们吧。

需要使用 tauri2 打包，但是依赖环境太复杂，本地电脑硬盘不够用，就用 PakePlus

热门包​

PakePLus 支持 arm 和 inter 架构的安装包，流行的程序安装包仅仅包含了 mac 的 arm(M 芯片)版本 和 windows 的 Inter（x64）版本 和 Linux 的 x64 版本，如果需要更多架构的安装包，请使用 PakePlus 单独编译自己需要的安装包。热门包的下载地址请到官方文档下载体验

常见问题

mac提示：应用已随坏​

这是因为没有给苹果给钱，所以苹果会拒绝你的应用。

解决办法：

Mac 用户可能在安装时看到“应用已损坏”的警告。 请点击“取消”，然后运行以下命令，输入电脑密码后，再重新打开应用：(这是由于应用需要官方签名，才能避免安装后弹出“应用已损坏”的提示，但官方签名的费用每年 99 美元...因此，需要手动绕过签名以正常使用)

sudo xattr -r -d com.apple.quarantine /Applications/PakePlus.app

 当你打包应用时，Mac 用户可能在安装时看到“应用已损坏”的警告。 请点击“取消”，然后运行以下命令，再重新打开应用：

sudo xattr -r -d com.apple.quarantine /Applications/你的软件名称.app

为什么把私钥写在代码里是一个致命错误

在技术社区经常能看到一些开发者分享的教训，前几天就有人发帖讲述一位Java开发者因同事将私钥直接硬编码在代码里而感到愤怒的事情。这种情况虽然听起来可笑，但在开发团队中却相当常见，尤其对于经验不足的程序员来说。

为什么把私钥写在代码里如此危险？

1. 代码会被分享和同步

代码通常会提交到Git或SVN等版本控制系统中。一旦私钥被提交，团队中的每个人都能看到这些敏感信息。即使后来删除了私钥，在历史记录中依然可以找到。有开发者就分享过真实案例：团队成员意外将AWS密钥提交到GitHub，结果第二天账单暴增数千元——有人利用泄露的密钥进行了挖矿活动。

2. 违反安全和职责分离原则

在规范的开发流程中，密钥管理和代码开发应该严格分离。通常由运维团队负责密钥管理，而开发人员则不需要（也不应该）直接接触生产环境的密钥。这是基本的安全实践。

3. 环境迁移的噩梦

当应用从开发环境迁移到测试环境，再到生产环境时，如果密钥硬编码在代码中，每次环境切换都需要修改代码并重新编译。这不仅效率低下，还容易出错。

正确的做法

业内已有多种成熟的解决方案：

• 使用环境变量存储敏感信息


• 采用专门的配置文件（确保加入.gitignore）


• 使用AWS KMS、HashiCorp Vault等专业密钥管理系统


• 在CI/CD流程中动态注入密钥

有开发团队就曾经花费两周时间清理代码中的硬编码密钥。其中甚至发现了一个已离职员工留下的"临时"数据库密码，注释中写着"临时用，下周改掉"——然而那个"下周"已经过去五年了。

作为专业开发者，应当始终保持良好的安全习惯。将私钥硬编码进代码，就像把家门钥匙贴在门上一样不可理喻。

这个教训值得所有软件工程师引以为戒。

引言.我不是鸽子大王！！

哈喽大家好！距离我上次发文已经过去半个月了，差点又变回了那只熟悉的“老鸽子”。不行，我不能堕落！我还没有将 Web3D 推广到普罗大众，还没有让更多人感受到三维图形的魅力 (其实是还没有捞着米)。怀着这样的心情，我决定重新振作，继续为大家带来更多关于 Three.js 和 Shader 的进阶内容。

0.前置条件

欢迎阅读本篇文章！在深入探讨 Three.js 和 Shader (GLSL) 的进阶内容之前，确保您已经具备以下基础知识：

1. Hero Section 概览

Hero Section 是网页设计中的一个术语，通常指页面顶部的一个大型横幅区域。但对于开发人员而言，这个概念可以更直观地理解为用户在访问网站的瞬间所感受到的视觉冲击，或者促使用户停留在该网站的关键原因因素。

话说这天老何接到了一个私活

起始钱不钱的无所谓！主要是想挑战一下自己(不是)。最后的成品如图所示 （互动方式为鼠标滑动 + 鼠标点击 GIF 压缩太多了内容了，实际要好看很多）。

PC端在线预览地址: fluid-light.vercel.app

Debug调试界面: fluid-light.vercel.app/#debug

源码地址: github.com/hexianWeb/f…

2.基础场景搭建

首先我来为你解读一下这个场景里面有什么，他非常简单。只有一个可以接受光照影响的平面几何体以及数个点光源构成，仅此而已。

让我去掉后处理以及一些页面文本元素展示给你看

构建这样的一个基础场景不难。

2.1 构建平面几何体

让我们先来解决平面几何体

值得注意的是，为了让显示效果更好，我使用了正交相机并让平面覆盖整个视窗大小

    this.geometry = new THREE.PlaneGeometry(2 * 屏幕宽高比, 2);

然后构建相应的物理材质，可以去 polyhaven 下载一些自己喜欢的texture 并下载下来。

根据右边的分类选择纹理大类细分，随后选择想要下载的纹理点击下载。

因为我们本质是需要 Displacement Texture置换贴图 & Normal Texture 法线贴图

所以不需要太在意这个纹理是作用在什么物件上面的

随后将纹理导入后赋予材质相应的属性，并对部分参数进行调整。通常直接赋予displacementMap 后 Threejs 中显示平面的凹凸会特别明显。所以记得通过

displacementScale来调整相应的大小。

    this.material = new THREE.MeshPhysicalMaterial({

      color: '#121423',

      metalness: 0.59,

      roughness: 0.41,

      displacementMap: 下载的纹理贴图,

      displacementScale: 0.1,

      normalMap: 下载的法线贴图,

      normalScale: new THREE.Vector2(0.68, 0.75),

      side: THREE.FrontSide

    });

最后将物体加入场景即可

    this.mesh = new THREE.Mesh(this.geometry, this.material);

    scene.add(this.mesh);

(tips:MeshStandardMaterial 和 MeshPhysicalMaterial 适合需要真实感光照和复杂物理特性的场景，但性能消耗较高。如果您的电脑出现卡顿可以选择消耗较少性能的物理材质)

2.2 灯光加入战场

在本案例中，高级感的来源之一就是灯光的变换。如果您足够细心，可能会注意到一些更微妙的细节：场景中的灯光并不是简单地从 A Color 切换到 B Color，而是同时存在多个光源，并且它们的强度也在动态变化。这种设计使得场景的光影效果更加丰富和立体。

如果场景中只有一个光源，效果可能会显得单调。而本案例中，灯光的变化呈现出一种层次感：中间是白色，周围还有一层类似年轮的光圈，最后逐渐扩散为纯色背景。这种效果的关键在于同一时间场景中存在多个点光源。虽然多个光源会显著增加性能消耗，但为了实现唯美的视觉效果，这是值得的。

让我们逐步分析灯光是如何实现的。

1. 封装创建点光源的函数

为了简化代码并提高复用性，我们可以先封装一个创建点光源的函数。这个函数会返回一个包含光源对象和目标颜色的对象。

  createPointLight(intensity) {

    const light = new THREE.PointLight(

      0xff_ff_ff,

      intensity,

      100,

      Math.random() * 10

    );

    light.position.copy(this.lightPosition); //所有的光源都同步在一个位置

    return {

      object: light,

      targetColor: new THREE.Color()

    };

  }

2. 生成多个点光源

接下来，我们可以调用这个函数生成多个点光源，并将它们添加到场景中。

this.colors = [

      new THREE.Color('orange'),

      new THREE.Color('red'),

      new THREE.Color('red'),

      new THREE.Color('orange'),

      new THREE.Color('lightblue'),

      new THREE.Color('green'),

      new THREE.Color('blue'),

      new THREE.Color('blue')

];    

this.lights = [

      this.createPointLight(2),

      this.createPointLight(3),

      this.createPointLight(2.5),

      this.createPointLight(10),

      this.createPointLight(2),

      this.createPointLight(3),

];



// 初始化灯光颜色

const numberLights = this.lights.length;

for (let index = 0; index < numberLights; index++) {

      const colorIndex = Math.min(index, this.colors.length - 1);

      this.lights[index].object.color.copy(this.colors[colorIndex]);

}



for (const light of this.lights) this.scene.add(light.object);

3. 动态调整光源强度

在场景中，所有光源同时存在，但它们的强度会有所不同。每次由光照强度为 10 的光源担任场景的主色。当用户点击场景时，灯光会像上楼梯或者传送带一样逐步切换，即由新的点光源担任场景主色。

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,

8                           8"b,    "Ya

8                           8  "b,    "Ya

8                    aa=D光源=a8,   "b,  "Ya

8                    8"b,    "Ya   "8""""""8

8                    8  "b,    "Ya  8      8

8             a=C光源=8,   "b,    "Ya8      8

8             8"b,    "Ya   "8"""""""      8

8             8  "b,    "Ya  8             8

8      a=B光源=8,   "b,    "Ya8             8

8      8"b,    "Ya   "8"""""""             8

8      8  "b,    "Ya  8                    8

8=A光源=,   "b,    "Ya8                    8

8"b,    "Ya   "8"""""""                    8

8  "b,    "Ya  8                           8

8,   "b,    "Ya8                           8

 "Ya   "8"""""""                           8

   "Ya  8                                  8

     "Ya8                                  8

       """""""""""""""""""""""""""""""""""""

让我们看看代码是如何实现的吧

    window.addEventListener('click', () => {

      // 打乱颜色数组（看个人喜好)

      this.colors = [...this.colors.sort(() => Math.random() - 0.5)];

       // 标记开始颜色过渡

        this.colorTransition = true;



        // 为每个灯光设置目标颜色

        const numberLights = this.lights.length;

        for (let index = 0; index < numberLights; index++) {

          const colorIndex = Math.min(index, this.colors.length - 1);

          this.lights[index].targetColor = this.colors[colorIndex].clone();

        }

    });

然后再Render函数中以easeing方式更新颜色

  update() {

    // 只在需要时更新颜色

    if (this.colorTransition) {

        const numberLights = this.lights.length;

        const baseSmooth = 0.25;

        const smoothIncrement = 0.05;



        let allTransitioned = true; // 检查所有颜色是否已完成过渡



        for (let index = 0; index < numberLights; index++) {

          const smoothTime = baseSmooth + index * smoothIncrement;



          // 使用目标颜色进行平滑过渡

          const currentColor = this.lights[index].object.color;

          const targetColor = this.lights[index].targetColor;



          this.dampC(currentColor, targetColor, smoothTime, delta);



          // 检查是否还在过渡

          if (!this.isColorClose(currentColor, targetColor)) {

            allTransitioned = false;

          }

        }



        // 如果所有颜色都已完成过渡，停止更新

        if (allTransitioned) {

          this.colorTransition = false;

        }

    }

  }

3.后处理完善场景

在完成了场景的基本构建之后，我们已经实现了大约 80% 的内容。即使现在加上 UI，效果也不会太差。不过，为了让场景更具视觉冲击力和艺术感，我们可以通过后处理（Post Processing）技术来进一步提升质感。

使用 UnrealBloomPass 和 FilmPass

在本文中，我们将使用 UnrealBloomPass（辉光效果）和 FilmPass（电影滤镜）来增强场景的视觉效果。以下是具体的实现步骤：

这里的具体参数需要看个人品味进行调试。同款参数可以从这里看我的源码。具体路径位于src\js\world\effect.js

    this.composer = new EffectComposer(this.renderer);

    this.composer.addPass(this.renderPass);

    this.composer.addPass(this.bloomPass);

	this.composer.addPass(this.filmPass);

此时页面的质感是不是一下就上来了呢？

最后我们需要添加最关键的一部，就是画面扭曲。

这里我们需要用到 Threejs 的 ShaderPass,让我们来创建一个初始的ShaderPass,仅将 EffectComposer 的读取缓冲区的图像内容复制到其写入缓冲区，而不应用任何效果。

具体内容你可以从 Threejs 后处理中了解到更多

import { ShaderPass } from 'three/addons/postprocessing/ShaderPass.js';



const BaseShader = {



	name: 'BaseShader',



	uniforms: {



		'tDiffuse': { value: null },

		'opacity': { value: 1.0 }



	},



	vertexShader: /* glsl */`



		varying vec2 vUv;



		void main() {



			vUv = uv;

			gl_Position = projectionMatrix * modelViewMatrix * vec4( position, 1.0 );



		}`,



	fragmentShader: /* glsl */`



		uniform float opacity;



		uniform sampler2D tDiffuse;



		varying vec2 vUv;



		void main() {



			vec4 texel = texture2D( tDiffuse, vUv );

			gl_FragColor = opacity * texel;





		}`



};



const BasePass = new ShaderPass( BaseShader );

此时画面不会有任何变化

让我们对uv进行简单操纵,让其读取tDiffuse时可以发生扭曲

      vec2 uv = vUv;

      uv.y += sin(uv.x * frequency + offset) * amplitude;

      gl_FragColor = texture2D(tDiffuse, uv);

最后得到效果

4.最后一些话

技术的未来与前端迁移

随着 AI 技术的快速发展，各类技术的门槛正在大幅降低，以往被视为高门槛的 3D 技术也不例外。与此同时，过去困扰开发者的数字资产构建成本问题，也正在被最新的 3D generation 技术所攻克。这意味着，在不久的将来，前端开发将迎来一次技术迁移，开发者需要掌握更新颖的交互方式和更出色的视觉效果。

为什么选择 Three.js？

Three.js 作为最流行的 WebGL 库之一，不仅简化了三维图形的开发流程，还提供了丰富的功能和强大的扩展性。无论是创建复杂的 3D 场景，还是实现炫酷的视觉效果，Three.js 都能帮助开发者快速实现目标。

本专栏的愿景

本专栏的愿景是通过分享 Three.js 的中高级应用和实战技巧，帮助开发者更好地将 3D 技术应用到实际项目中，打造令人印象深刻的 Hero Section。我们希望通过本专栏的内容，能够激发开发者的创造力，推动 Web3D 技术的普及和应用。

加入社区，共同成长

如果您对 Threejs 这个 3D 图像框架很感兴趣，或者您也深信未来国内会涌现越来越多 3D 设计风格的网站，欢迎加入 ice 图形学社区。这里是国内 Web 图形学最全的知识库，致力于打造一个全新的图形学生态体系！您可以在认证达人里找到我这个 Threejs 爱好者和其他大佬。

此外，如果您很喜欢 Threejs 又在烦恼其原生开发的繁琐，那么我诚邀您尝试 Tresjs 和 TvTjs, 他们都是基于 Vue 的 Threejs 框架。 TvTjs 也为您提供了大量的可使用案例，并且拥有较为活跃的开发社区，在这里你能碰到志同道合的朋友一起做开源！

5.下期预告

未来科技？机器人概念官网来袭 ！！！

6. 往期回顾

2025 年了，我不允许有前端不会用 Trae 让页面 Hero Section 变得高级！！！(Threejs)

2024年了，前端人是时候给予页面一点 Hero Section 魔法了！！！ (Three.js)

2023 年了，还有前端人不知道 commit 规范 ？

前言

老板：新的需求不是上线了嘛，怎么用户看到的还是老的页面呀
窝囊废：让用户刷新一下页面，或者清一下缓存
老板：那我得告诉用户，刷新一下页面，或者清一下缓存，才能看到新的页面呀，感觉用户体验不好啊，不能直接刷新页面嘛？
窝囊废：可以解决（OS：一点改的必要没有，用户全是大聪明）

产品介绍

c端需要经常进行一些文案调整，一些老版的文字字眼可能会导致一些舆论问题，所以就需要更新之后刷新页面，让用户看到新的页面。

思考问题为什么产生

项目是基于vue的spa应用，通过nginx代理静态资源，配置了index.html协商缓存，js、css等静态文件Cache-Control,按正常前端重新部署后， 用户重新访问系统，已经是最新的页面。

但是绝大部份用户都是访问页面之后一直停留在此页面，这时候前端部署后，用户就无法看到新的页面，需要用户刷新页面。

产生问题

• 如果后端接口有更新，前端重新部署后，用户访问老的页面，可能会导致接口报错。
• 如果前端部署后，用户访问老的页面，可能无法看到新的页面，需要用户刷新页面，用户体验不好。
• 出现线上bug，修复完后，用户依旧访问老的页面，仍会遇到bug。

解决方案

1. 前后端配合解决

• WebSocket
• SSE(Server-Send-Event)

2. 纯前端方案 以下示例均以vite+vue3为例；

• 轮询html Etag/Last-Modified

在App.vue中添加如下代码

const oldHtmlEtag = ref();

const timer = ref();

const getHtmlEtag = async () => {

  const { protocol, host } = window.location;

  const res = await fetch(`${protocol}//${host}`, {

    headers: {

      "Cache-Control": "no-cache",

    },

  });

  return res.headers.get("Etag");

};



  oldHtmlEtag.value = await getHtmlEtag();

  clearInterval(timer.value);

  timer.value = setInterval(async () => {

    const newHtmlEtag = await getHtmlEtag();

    console.log("---new---", newHtmlEtag);

    if (newHtmlEtag !== oldHtmlEtag.value) {

      Modal.destroyAll();

      Modal.confirm({

        title: "检测到新版本，是否更新？",

        content: "新版本内容：",

        okText: "更新",

        cancelText: "取消",

        onOk: () => {

          window.location.reload();

        },

      });

    }

  }, 30000);

• versionData.json

自定义plugin，项目根目录创建/plugins/vitePluginCheckVersion.ts

import path from "path";

import fs from "fs";

export function checkVersion(version: string) {

  return {

    name: "vite-plugin-check-version",

    buildStart() {

      const now = new Date().getTime();

      const version = {

        version: now,

      };

      const versionPath = path.join(__dirname, "../public/versionData.json");

      fs.writeFileSync(versionPath, JSON.stringify(version), "utf8", (err) => {

        if (err) {

          console.log("写入失败");

        } else {

          console.log("写入成功");

        }

      });

    },

  };

}

在vite.config.ts中引入插件

import { checkVersion } from "./plugins/vitePluginCheckVersion";

plugins: [

  vue(),

  checkVersion(),

]

在App.vue中添加如下代码

const timer = ref()

const checkUpdate = async () => {

  let res = await fetch('/versionData.json', {

    headers: {

      'Cache-Control': 'no-cache',

    },

  }).then((r) => r.json())

  if (!localStorage.getItem('demo_version')) {

    localStorage.setItem('demo_version', res.version)

  } else {

    if (res.version !== localStorage.getItem('demo_version')) {

      localStorage.setItem('demo_version', res.version)

      Modal.confirm({

        title: '检测到新版本，是否更新？',

        content: '新版本内容：' + res.content,

        okText: '更新',

        cancelText: '取消',

        onOk: () => {

          window.location.reload()

        },

      })

    }

  }

}



onMounted(()=>{

  clearInterval(timer.value)

  timer.value = setInterval(async () => {

   checkUpdate()

  }, 30000)

})

• plugin-web-update-notification

Use

// vite.config.ts

import { defineConfig } from 'vite'

import vue from '@vitejs/plugin-vue'

import { webUpdateNotice } from '@plugin-web-update-notification/vite'



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

export default defineConfig({

  plugins: [

    vue(),

    webUpdateNotice({

      logVersion: true,

    }),

  ]

})

作者：李暖阳啊
来源：juejin.cn/post/7439905609312403483

console.log的弊端

1. 影响性能（轻微但可优化）

console.log 会占用 内存 和 CPU 资源，尤其是在循环或高频触发的地方（如 mousemove 事件）。
虽然现代浏览器优化了 console，但大量日志仍可能导致 轻微性能下降。

2. 暴露敏感信息（安全风险）

可能会 泄露 API 接口、Token、用户数据 等敏感信息，容易被恶意利用。

3. 干扰调试（影响开发者体验）

生产环境日志过多，可能会 掩盖真正的错误信息，增加调试难度。
开发者可能会误以为某些 console.log 是 预期行为，而忽略真正的 Bug。

4. 增加代码体积（影响加载速度）

即使 console.log 本身很小，但 大量日志 会增加打包后的文件体积，影响 首屏加载速度。

解决方案：移除生产环境的 console.log

1. 使用 Babel 插件

在 babel.config.js 中配置：

module.exports = {

  presets: [

    '@vue/cli-plugin-babel/preset',

  ],

  plugins: [

    ['@babel/plugin-proposal-optional-chaining'],

    ...process.env.NODE_ENV === 'production' ? [['transform-remove-console', { exclude: ['info', 'error', 'warn'] }]] : []

  ]

}

特点：

• 不影响源码，仅在生产环境生效，开发环境保留完整 console。


• 配置简单直接，适合快速实现基本需求。


• 依赖 Babel 插件

2. 使用 Terser 压缩时移除（Webpack/Vite 默认支持）

在 vite.config.js 或 webpack.config.js 中配置：

module.exports = {

  chainWebpack: (config) => {

    config.optimization.minimizer("terser").tap((args) => {

      args[0].terserOptions.compress = {

        ...args[0].terserOptions.compress,

        drop_console: true,       // 移除所有 console

        pure_funcs: ["console.log"], // 只移除 console.log，保留其他

      };

      return args;

    });

  },

};

特点：

• 不影响源码，仅在生产环境生效，开发环境保留完整 console。


• 避免 Babel 插件兼容性问题


• 需要额外配置

3. 自定义 console 包装函数（按需控制）

// utils/logger.js

const logger = {

  log: (...args) => {

    if (process.env.NODE_ENV !== "production") {

      console.log("[LOG]", ...args);

    }

  },

  warn: (...args) => {

    console.warn("[WARN]", ...args);

  },

  error: (...args) => {

    console.error("[ERROR]", ...args);

  },

};



export default logger;

使用方式

import logger from "./utils/logger";



logger.log("Debug info"); // 生产环境自动不打印

logger.error("Critical error"); // 始终打印

特点：

• 可以精细控制日志，可控性强，可以自定义日志级别。


• 不影响 console.warn 和 console.error。


• 需要手动替换 console.log

提醒一下

双Token机制并没有从根本上解决安全性的问题，本文章只是提供一个思路，具体是否选择请大家仔细斟酌考虑，笔者水平有限，非常抱歉对你造成不好的体验。

token有效期设置问题

最近在做用户认证模块的后端功能开发，之前就有一个问题困扰了我好久，就是如何设置token的过期时间，前端在申请后端登录接口成功之后，会返回一个token值，存储在用户端本地，用户要访问后端的其他接口必须通过请求头带上这个token值，但是这个token的有效期应该设置为多少?

• 
  
  
  
  • 
    
    
    
    • 一旦token泄露，攻击者可长期冒充用户身份，直到token过期，服务端无法限制其访问用户数据
    
    
    • 虽然可以依赖黑名单机制，但会增加系统复杂度，还要进行系统监测
    
    
    • 如果在这段时间恶意用户利用未过期的条款持续调用后端API将会导致资源耗尽或产生巨额费用
    
    
    
    
  
  
  
  

所以有没有两者都兼顾的方案呢?

双token无感刷新方案

传统的token方案要么频繁要求用户重新登录，要么面临长期有效的安全风险

但是双token无感刷新机制，通过组合设计，在保证安全性的情况下，实现无感知的认证续期

核心设计

大致的执行流程如下

用户登录之后，后端返回access_token和refresh_token响应给前端，前端将两个token存储在用户本地

在用户端发起前端请求，访问后端接口，在请求头中携带上access_token

前端会对access_token的过期时间进行检测，当access_token过期前一分钟，前端通过refresh_token向后端发起请求，后端判断refresh_token是否有效，有效则重新获取新的access_token，返回给前端替换掉之前的access_token存储在用户本地，无效则要求用户重新认证

这样的话对于用户而言token的刷新是无感知的，不会影响用户体验，只有当refresh_token失效之后，才需要用户重新进行登录认证，同时，后端可以通过对用户refresh_token的管理来限制用户对后端接口的请求，大大提高了安全性

有了这个思路，写代码就简单了

@Service

public class LoginServiceImpl implements LoginService {



    @Autowired

    private JwtUtils jwtUtils;



    // token过期时间

    private static final Integer TOKEN_EXPIRE_DAYS =5;

    // token续期时间



    private static final Integer TOKEN_RENEWAL_MINUTE =15;



    @Override

    public boolean verify(String refresh_token) {

        Long uid = jwtUtils.getUidOrNull(refresh_token);

        if (Objects.isNull(uid)) {

            return false;

        }

        String key = RedisKey.getKey(RedisKey.USER_REFRESH_TOKEN,uid);

        String realToken = RedisUtils.getStr(key);

        return Objects.equals(refresh_token, realToken);

    }



    @Override

    public void renewalTokenIfNecessary(String refresh_token) {

        Long uid = jwtUtils.getUidOrNull(refresh_token);

        if (Objects.isNull(uid)) {

            return;

        }

        String refresh_key = RedisKey.getKey(RedisKey.USER_REFRESH_TOKEN, uid);

        long expireSeconds = RedisUtils.getExpire(refresh_key, TimeUnit.SECONDS);

        if (expireSeconds == -2) { // key不存在，refresh_token已过期

            return;

        }

        String access_key = RedisKey.getKey(RedisKey.USER_ACCESS_TOKEN, uid);

        RedisUtils.expire(access_key, TOKEN_RENEWAL_MINUTE, TimeUnit.MINUTES);

    }



    @Override

    @Transactional(rollbackFor = Exception.class)

    @RedissonLock(key = "#uid")

    public LoginTokenResponse login(Long uid) {

        String refresh_key = RedisKey.getKey(RedisKey.USER_REFRESH_TOKEN, uid);

        String access_key = RedisKey.getKey(RedisKey.USER_ACCESS_TOKEN, uid);

        String refresh_token = RedisUtils.getStr(refresh_key);

        String access_token;

        if (StrUtil.isNotBlank(refresh_token)) { //刷新令牌不为空

            access_token = jwtUtils.createToken(uid);

            RedisUtils.set(access_key, access_token, TOKEN_RENEWAL_MINUTE, TimeUnit.MINUTES);

            return LoginTokenResponse.builder()

                    .refresh_token(refresh_token).access_token(access_token)

                    .build();

        }

        refresh_token = jwtUtils.createToken(uid);

        RedisUtils.set(refresh_key, refresh_token, TOKEN_EXPIRE_DAYS, TimeUnit.DAYS);

        access_token = jwtUtils.createToken(uid);

        RedisUtils.set(access_key, access_token, TOKEN_RENEWAL_MINUTE, TimeUnit.MINUTES);

        return LoginTokenResponse.builder()

                .refresh_token(refresh_token).access_token(access_token)

                .build();

    }

}}

注意事项

安全问题

双Token机制并没有从根本上解决安全性的问题，它只是尝试通过改进设计，优化用户体验，全面的安全策略需要多层防护，分别针对不同类型的威胁和风险，而不仅仅依赖于Token的管理方式或数量

安全是一个持续对抗的过程，关键在于提高攻击者的成本，而非追求绝对防御。

"完美的认证方案不存在，但聪明的权衡永远存在。"

本笔者水平有限，望各位海涵

如果文章中有不对的地方，欢迎大家指正。

大家好呀，我是猿java。

在分布式系统中，我们经常听到灰度发布这个词，那么，什么是灰度发布？为什么需要灰度发布？如何实现灰度发布？这篇文章，我们来聊一聊。

1. 什么是灰度发布？

简单来说，灰度发布也叫做渐进式发布或金丝雀发布，它是一种逐步将新版本应用到生产环境中的策略。相比于一次性全量发布，灰度发布可以让我们在小范围内先行测试新功能，监控其表现，再决定是否全面推开。这样做的好处是显而易见的：

2. 原理解析

要理解灰度发布，我们需要先了解一下它的基本流程：

在这个过程中，关键在于如何切分流量，确保新旧版本平稳过渡。常见的切分方式包括：

• 基于用户ID：根据用户的唯一标识，将部分用户指向新版本。


• 基于地域：先在特定地区进行发布，观察效果后再扩展到其他地区。


• 基于设备：例如，先在Android或iOS用户中进行发布。

3. 示例演示

为了更好地理解灰度发布，接下来，我们通过一个简单的 Java示例来演示基本的灰度发布策略。假设我们有一个简单的 Web应用，有两个版本的登录接口/login/v1和/login/v2，我们希望将百分之十的流量引导到v2，其余流量继续使用v1。

3.1 第一步：引入灰度策略

我们可以通过拦截器（Interceptor）来实现流量的切分。以下是一个基于Spring Boot的简单实现：

import org.springframework.stereotype.Component;

import org.springframework.web.servlet.HandlerInterceptor;



import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.util.Random;



@Component

public class GrayReleaseInterceptor implements HandlerInterceptor {



    private static final double GRAY_RELEASE_PERCENT = 0.1; // 10% 流量



    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        String uri = request.getRequestURI();

        if ("/login".equals(uri)) {

            if (isGrayRelease()) {

                // 重定向到新版本接口

                response.sendRedirect("/login/v2");

                return false;

            } else {

                // 使用旧版本接口

                response.sendRedirect("/login/v1");

                return false;

            }

        }

        return true;

    }



    private boolean isGrayRelease() {

        Random random = new Random();

        return random.nextDouble() < GRAY_RELEASE_PERCENT;

    }

}

3.2 第二步：配置拦截器

在Spring Boot中，我们需要将拦截器注册到应用中：

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.context.annotation.Configuration;

import org.springframework.web.servlet.config.annotation.*;



@Configuration

public class WebConfig implements WebMvcConfigurer {



    @Autowired

    private GrayReleaseInterceptor grayReleaseInterceptor;



    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        registry.addInterceptor(grayReleaseInterceptor).addPathPatterns("/login");

    }

}

3.3 第三步：实现不同版本的登录接口

import org.springframework.web.bind.annotation.*;



@RestController

@RequestMapping("/login")

public class LoginController {



    @GetMapping("/v1")

    public String loginV1(@RequestParam String username, @RequestParam String password) {

        // 旧版本登录逻辑

        return "登录成功 - v1";

    }



    @GetMapping("/v2")

    public String loginV2(@RequestParam String username, @RequestParam String password) {

        // 新版本登录逻辑

        return "登录成功 - v2";

    }

}

在上面三个步骤之后，我们就实现了登录接口地灰度发布：

• 当用户访问/login时，拦截器会根据设定的灰度比例（10%）决定请求被重定向到/login/v1还是/login/v2。


• 大部分用户会体验旧版本接口，少部分用户会体验新版本接口。

3.4 灰度发布优化

上述示例，我们只是一个简化的灰度发布实现，实际生产环境中，我们可能需要更精细的灰度策略，例如：

4. 为什么需要灰度发布？

在实际工作中，为什么我们要使用灰度发布？这里我们总结了几个重要的原因。

4.1 降低发布风险

每次发布新版本，尤其是功能性更新或架构调整，都会伴随着一定的风险。即使经过了充分的测试，实际生产环境中仍可能出现意想不到的问题。灰度发布通过将新版本逐步推向部分用户，可以有效降低全量发布可能带来的风险。

举个例子，假设你上线了一个全新的支付功能，直接面向所有用户开放。如果这个功能存在严重 bug，可能导致大量用户无法完成支付，甚至影响公司声誉。而如果采用灰度发布，先让10%的用户体验新功能，发现问题后只需影响少部分用户，修复起来也更为迅速和容易。

4.2 快速回滚

在传统的全量发布中，一旦发现问题，回滚到旧版本可能需要耗费大量时间和精力，尤其是在高并发系统中，数据状态的同步与恢复更是复杂。而灰度发布由于新版本只覆盖部分流量，问题定位和回滚变得更加简单和快速。

比如说，你在灰度发布阶段发现新版本的某个功能在某些特定条件下会导致系统崩溃，立即可以停止向新用户推送这个版本，甚至只针对受影响的用户进行回滚操作，而不用影响全部用户的正常使用。

4.3 实时监控与反馈

灰度发布让你有机会在真实的生产环境中监控新版本的表现，并收集用户的反馈。这些数据对于评估新功能的实际效果至关重要，有助于做出更明智的决策。

举个具体的场景，你新增了一个推荐算法，希望提升用户的点击率。在灰度发布阶段，你可以监控新算法带来的点击率变化、服务器负载情况等指标，确保新算法确实带来了预期的效果，而不是引入了新的问题。

4.4 提升用户体验

通过灰度发布，你可以在推出新功能时，逐步优化用户体验。先让一部分用户体验新功能，收集他们的使用反馈，根据反馈不断改进，最终推出一个更成熟、更符合用户需求的版本。

举个例子，你开发了一项新的用户界面设计，直接全量发布可能会让一部分用户感到不适应或不满意。灰度发布允许你先让一部分用户体验新界面，收集他们的意见，进行必要的调整，再逐步扩大使用范围，确保最终发布的版本能获得更多用户的认可和喜爱。

4.5 支持A/B测试

灰度发布是实现A/B测试的基础。通过将用户随机分配到不同的版本，你可以比较不同版本的表现，选择最优方案进行全面推行。这对于优化产品功能和提升用户体验具有重要意义。

比如说，你想测试两个不同的推荐算法，看哪个能带来更高的转化率。通过灰度发布，将用户随机分配到使用算法A和算法B的版本，比较它们的表现，最终选择效果更好的算法进行全面部署。

4.6 应对复杂的业务需求

在一些复杂的业务场景中，全量发布可能无法满足灵活的需求，比如分阶段推出新功能、针对不同用户群体进行差异化体验等。灰度发布提供了更高的灵活性和可控性，能够更好地适应多变的业务需求。

例如，你正在开发一个面向企业用户的新功能，希望先让部分高价值客户试用，收集他们的反馈后再决定是否全面推广。灰度发布让这一过程变得更加顺畅和可控。

5. 总结

本文，我们详细地分析了灰度发布，它是一种强大而灵活的部署策略，能有效降低新版本上线带来的风险，提高系统的稳定性和用户体验。作为Java开发者，掌握灰度发布的原理和实现方法，不仅能提升我们的技术能力，还能为团队的项目成功保驾护航。

对于灰度发布，如果你有更多的问题或想法，欢迎随时交流！

6. 学习交流

如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。

于水增

故事背景

事情起源于之前做的海报编辑器，自己调试时无意中发现字体渲染好慢，第一反应就是网怎么变慢了，断网了？仔细一看才发现，淦！这几个字体资源咋这么大，难怪网速变慢了呢😁😁。

图片中的海报包含6种字体，其中最大的字体文件超过20M，而最长的网络加载时长已接近20s。所以海报实际效果图展示耗时太久，很影响用户体验。那就趁此机会跟大家聊聊 字体 这件小事。

字体文件为什么那么大？

🙋 DeepSeek同学来回答下大家：

这里所说的大体积的字体资源多数是指中文主要原因下边两点

• 中文字符数量庞大，英文仅 26 个字母 + 符号，中文（全字符集）包含 70,000+ 字符


• 字形结构复杂，字体文件需为每个字符存储独立的矢量轮廓数据，而汉字笔画复杂，每个字符需存储数百个控制点坐标（例如「龍」字的轮廓点数量可能是「A」的 10 倍以上）

总结下来就是咱们不光汉字多，书法也是五花八门，它是真小不了。如果你硬要压缩，我们只能从第一点入手，将字符数量进行缩减，比如保留 1000 个常用汉字。

web网站中常见字体格式

由于我司物料部门提供的为TTF格式，所以这里通过 思源黑体 给一个直观的对比：

• TTF 文件：16.9 MB


• WOFF2 文件：7.4 MB（压缩率约 60%）

两者为什么会差这么多，其实WOFF2 只是在 TTF/OTF 基础上添加了压缩和 Web 专用元数据，且WOFF2支持增量解码，也就是边下载边解析，文本可更快显示（即使字体未完全加载，不过有待考证）。

TTF有办法优化吗？

回归问题本身

首先来简单回顾下我们自定义的字体是如何在浏览器中完成渲染的

一般情况下我们对字体文件的引用方式为下边三种

• 通过绝对路径来引用，这种就是将字体文件打包在工程内，所以带来的结果就是工程打包文件体积太大

@font-face {

  font-family: 'xxx';

  src: url('../../assets/fonts.woff2')

}

• 第二种就是 CDN 中存放的字体文件，一般是通过这种方式来减少工程的编译后体积

@font-face {

  font-family: 'xxx';

  src: url('https://xxx.woff2')

}

• 通过 FontFace 构造一个字体对象

前两种一般是在浏览器构建 CSSOM 时，当遇到**<font style="color:rgba(0, 0, 0, 0.9);background-color:rgb(243, 243, 243);">url()</font>** 引用时会发起资源请求。第三种则是通过 js 来控制字体的加载流程，所以归根结底就是字体文件太大，导致网络资源下载速度慢，我们只能从优化字体大小的方向入手

确定解决方向

下面汇总下查到的具体几个优化方案，诸如提高网络传输效率，增加缓存之类的就不讲了，能够立竿见影的主要下边这两个方案

简单来说，字体子集化可单独食用，按需加载则必须要将字体前置子集化。才能完美实现按需加载。就我的这个项目而言，动态子集化方案不要太完美，毕竟一张海报本身就没几个字儿！所以我们这次将抛弃 CDN，通过动态的将服务本地中的字体资源子集化来实现字体的压缩效果。

这里我们使用python中的一个字体工具库 fontTools 来实现一个动态子集化，类似于 Google Fonts 的实现。核心思路就是将字符传给服务端，通过工具将传入的字符在本地字体文件中提取并返回给客户端，通过fontTools 还可以将TTF格式转化为和Web更搭的WOFF2格式。实现细节如下述代码所示

@app.route('/font/<font_name>', methods=['GET'])

def get_font_subset(font_name):

    # 获取本地字体文件路径

    font_path = os.path.join(FONTS_DIR, f"{font_name}.ttf")

    # 获取子集字符

    chars = request.args.get('text', '')

    # 字体文件格式

    format = request.args.get('format', 'woff2').lower()



    # 处理字符，去重

    unique_chars = ''.join(sorted(set(chars)))

    try:

        # 配置子集化选项

        options = Options()

        options.flavor = format if format in {'woff', 'woff2'} else 

        options.desubroutinize = True  # 增强兼容性

        subsetter = Subsetter(options=options)

        

        # 加载字体并生成子集

        font = TTFont(font_path)

        subsetter.populate(text=unique_chars)

        subsetter.subset(font)



        # 保存为指定格式

        buffer = io.BytesIO()

        font.save(buffer)

        buffer.seek(0)



        # 确定MIME类型

        mime_type = {

            'woff2': 'font/woff2',

            'woff': 'font/woff',

        }[format]



        # 创建响应并设置

        response = Response(buffer.read(), mimetype=mime_type)

        # 其他设置...

        return response



    except Exception as e:

        # 子集化失败...

前端代码中增加了一些字符提取的工作，我本身就是通过 FontFace Api 来请求字体资源的，所以我仅需将资源链接替换为子集化字体的接口就可以了，下面代码来描述字体的加载过程

// ...其他逻辑

Toast.loading('字体加载中')

// 遍历海报中的字体对象

[...new Set(fontFamilies)].forEach((fontName) => {

  // 在字体库中找到对应字体详细信息

  const obj = fontLibrary.find((el) => el?.value === fontName) ?? {};



  if (obj.value && obj.src) {

    // 处理海报中提取的文案集合

    const text = textMap[obj.value].join('');

    // 构建字体对象

    const font = new FontFace(

      obj.value,

      `url(http://127.0.0.1:5000/font/${obj.value}?text=${text}&format=woff2)`

    );

    // 加载字体

    font.load();

    // 添加到文档字体集中

    document.fonts.add(font);

  }

});

// 文档所有字体加载完毕后返回成功的 Promise

return document.fonts.ready.finally(() => Toast.destory());

好了，刷新下浏览器，来看看最终的效果：

这这 真立竿见影（主要是基数大😁😁），最终得到的结果就是，实际 22.4M 的字体文件，子集化后缩减到 3.6KB。实际效果图生成的时间由 20s+ 缩减到毫秒级（300ms 以内）。这下就无惧网速了吧！

结语

总的来说，优化字体加载的方案有很多，我们需要结合自己的实际业务场景来进行选型，字体子集化确实是一种高效且实用的优化手段，更多的实践思路可以参考下 Google fonts。

Electron实现静默打印小票

静默打印流程

1.渲染进程通知主进程打印

//渲染进程 data是打印需要的数据

window.electron.ipcRenderer.send('handlePrint', data)

2.主进程接收消息,创建打印页面

//main.ts

/* 打印页面 */

let printWindow: BrowserWindow | undefined

/**

 * @Author: yaoyaolei

 * @Date: 2024-06-07 09:27:22

 * @LastEditors: yaoyaolei

 * @description: 创建打印页面

 */

const createPrintWindow = () => {

  return new Promise<void>((resolve) => {

    printWindow = new BrowserWindow({

      ...BASE_WINDOW_CONFIG,

      title: 'printWindow',

      webPreferences: {

        preload: join(__dirname, '../preload/index.js'),

        sandbox: false,

        nodeIntegration: true,

        contextIsolation: false

      }

    })



    printWindow.on('ready-to-show', () => {

      //打印页面创建完成后不需要显示,测试时可以调用show查看页面样式(下面有我处理的样式图片)

      // printWindow?.show()

      resolve()

    })



    printWindow.webContents.setWindowOpenHandler((details: { url: string }) => {

      shell.openExternal(details.url)

      return { action: 'deny' }

    })



    if (is.dev && process.env['ELECTRON_RENDERER_URL']) {

      printWindow.loadURL(`${process.env['ELECTRON_RENDERER_URL']}/print.html`)

    } else {

      printWindow.loadFile(join(__dirname, `../renderer/print.html`))

    }

  })

}



ipcMain.on('handlePrint', (_, obj) => {

   //主进程接受渲染进程消息,向打印页面传递数据

  if (printWindow) {

    printWindow!.webContents.send('data', obj)

  } else {

    createPrintWindow().then(() => {

      printWindow!.webContents.send('data', obj)

    })

  }

})

3.打印页面接收消息，拿到数据渲染页面完成后通知主进程开始打印

<!doctype html>

<html>

<head>

  <meta charset="UTF-8" />

  <title>打印</title>

  <style>

  </style>

</head>



<body>



</body>

<script>

  window.electron.ipcRenderer.on('data', (_, obj) => {

  //这里是接受的消息,处理完成后将html片段放在body里面完成后就可以开始打印了

  //样式可以写在style里,也可以内联

    console.log('event, data: ', obj);

  //这里自由发挥

    document.body.innerHTML = '处理的数据'

  //通知主进程开始打印

    window.electron.ipcRenderer.send('startPrint')

  })

</script>

</html>

这个是我处理完的数据样式,这个就是print.html

4,5.主进程接收消息开始打印,并且通知渲染进程打印状态

ipcMain.on('startPrint', () => {

  //这里如果不指定打印机使用的是系统默认打印机,如果需要指定打印机,

  //可以在初始化的时候使用webContents.getPrintersAsync()获取打印机列表,

  //然后让用户选择一个打印机,打印的时候将打印机名称传过来

  printWindow!.webContents.print(

    {

      silent: true,

      margins: { marginType: 'none' }

      //deviceName:如果要指定打印机传入打印机名称

    },

    (success) => {

      //通知渲染进程打印状态

      if (success) {

        mainWindow.webContents.send('printStatus', 'success')

      } else {

        mainWindow.webContents.send('printStatus', 'error')

      }

    }

  )

})

完毕~

前言

在管理平台中，富文本编辑器是信息输入和内容编辑的重要工具，几乎是必不可少的功能模块。它不仅能帮助用户轻松创建和格式化文档、邮件、模版等内容，还支持多样化的输入方式，提升了内容管理的便捷性和效率。

遇事不决扔个富文本，随心所欲不逾矩

富文本编辑器的实现虽然为用户提供了极大的便利，但其背后的技术复杂度也不容小觑。实现一个全面且高效的富文本编辑器，涉及到跨浏览器兼容性、复杂的格式化操作、多媒体支持等多个技术难题，往往需要花费大量的人力物力。即便如此，富文本编辑器也不可能满足所有用户的需求。不同的用户对功能有着各自的偏好.对于用户来说，选择富文本编辑器时，也需要在功能性与操作便捷性之间进行取舍，找到最适合自己需求的解决方案。

碰到说做一个和word相同功能的富文本的领导，直接上砖头

我认为选择富文本要考虑以下这些重要的功能：

你很难想象竟然有不会英文的客户，强烈要求我们更换富文本编辑器

富文本测评

Tinymce

Tinymce是一个老牌做富文本的公司，文档和插件配置的自由度都不错，也支持自定义拓展。功能强大，可以完全作为用户的首选

免费版如下图所示：

评测一下Tinymce的优缺点：

优点:

缺点:

我司从5.X开始使用，目前已迭代到7.X（UI好看了好多）

不知道怎么选的情况下，选Tinymce肯定没错，当然也不能对Tinymce有太大要求，你会失望的

CKEditor

CKEditor也是一个老牌做富文本的公司， 5.0版本无论是功能还是UI做的相当不错，毫不夸张的说，这是我见过插件最丰富的富文本了

完整版如下图所示:

评测一下CKEditor的优缺点：

优点：

缺点：

最基础的免费版如下：

基于CKEditor的优缺点，推荐复杂文档编辑及格式化的业务使用

白嫖党不推荐，适合人民币玩家

Tiptap

Tiptap是一个模块化的编辑器, 官方解释是tipTap是一个无头编辑器，无头特征决定了完全自由。
自由扩展，自由定义。

它基于Prosemirror，完全可扩展且无渲染。可以轻松地将自定义外观、样式、位置等等

可以像这样:

也可以像这样：

灵活的API，不仅可以让你进行天马行空的布局，各种事件也可以让你用到飞起。作为一个后起之秀，迅速占领市场，赢得了大量客户的好评。真心推荐大家去使用一下！

下面评测一下Tiptap富文本

优点：

缺点:

经查阅资料，tiptap插件支持markdown格式，感谢 李里_lexy 和 imber的指正

想要多人协作的，不要考虑了：用它，用它，用它！

Quill

我司最开始使用的一款富文本。配置简单，UI也还不错。中文文档丰富，一天的时间就可以集成到项目中。

评测一下Quill的优缺点

优点:

缺点：

全局改样式的时候，从控制台中取一下html代码，然后全局替换一下忍忍也就算了。随着图片上传后，文档排版越来越麻烦，真的不能忍了。只能宣布这个富文本的倒计时了！

适合对图片没有太多需求，并且对文档没有太大格式需求的公司

个人开发蛮推荐的

wangEditor

国产之光，个人能做成这个样子，我还是由衷的佩服的。

有兴趣的掘友们可以看下为什么都说富文本编辑器是天坑?。觉得自己还可以的掘友可以试着做做下面这两个小功能？

不要小看这个小功能，我敢打赌，95%的程序员至少一周的时间或者压根做不出来

赌一包辣条，立贴为证

好了，回到正题。我们评测一下wangEditor富文本

优点:

缺点:

首先向wangEditor开源作者双越老师表示敬意，因为开源想盈利太不容易了，基本都是为爱发电

不考虑移动端的，并且不介意暂停维护的可以使用

否则直接pass吧，用Jodit或者wangEditor-next替代吧

wangEditor-next

wangEditor-next的作者cycleccc在简介中这样写道：

wangeditor 因作者个人原因短期不再维护，wangEditor-next为fork版本,将在尽量不 Breaking change 的前提下继续维护。

此外，wangEditor-next也不再是个人单打独斗了，开始多人团队协作。最近几个月更新也很频繁，近3000次commit也能看出该团队的活跃度和持续产出，这种高频次的更新不仅反映了团队对用户反馈的响应速度，确保项目能够持续迭代并满足用户需求。

期待wangEditor-next能够在开源和盈利中找到平衡点，期待国人的产品能够获得广泛认可，为用户提供优质的体验。

Jodit

免费版功能如下:

白嫖党的福音

大招:收费版来了

在原有的基础上又增加了以下实用的功能

一次性付费99$（一个项目），399$（无限项目）即可解锁，我觉得超值

相比于wangEditor，我更推荐Jodit。无论是免费版，还是付费版，都值得拥有和尝试

Editor.js

Editor也是一个模块化编辑器。与Tiptap有很多相似之处，如模块化设计，可拓展性等等。这里不详细展开了，主要说一下两个编辑器的不同点:

Editor默认使用JSON格式的数据，更易于展示和分析，除非有强烈需求，否则慎选

Slate

引用一下原文:

Slate是一个 完全 可定制的富文本编辑器框架。

Slate 让你构建像 Medium, Dropbox Paper或者是 Google Docs(它们正成为web应用的标杆)这样丰富，直观的编辑器，而不会让你在代码实现上深陷复杂度的泥潭。

文档介绍的很酷，但目前是beta版本，且仍没有计划发布正式版。我没有用过，不做过多的评价，有兴趣的可以自己去体验一下

开源项目，没有大公司的支持，完全是自愿奉献。30k的star用户默默的支持，期待早日发布

很酷的架构设计，推荐大家去体验一下，期待Slate的早日发布

medium-editor

一款轻量级的编辑器，压缩后约为28KB, 除了工具栏可以显示在文本上方，支持内联编辑外，我没有找到其他的优点。4年没有更新, 插件拓展非常不友好。对不起这16K的star

如果你喜欢这种编辑方式，还可以体验一下。除此外，直接Pass

Squire

又是一款轻量级的编辑器，压缩完才11.5kb，相对于其它的富文本来说是非常的小了，推荐功能不复杂的场景使用

轻量级的编辑器，相较于medium-editor更符合用户习惯，推荐功能不复杂的场景使用

UEditor

看到上面这个图片，估计很多用户直接就断绝了使用的想法吧。确实，UI设计的真不好看，不符合当今的审美。可是在小10年前，用百度UEditor的比比皆是，只能说此一时彼一时。

我们评测一下UEditor富文本

优点:

缺点:

不吐槽了，直接用省略号吧。祭奠我的青春

久远的富文本，官方已经不维护了，不推荐使用

UEditor Plus

UEditor Plus 是基于 UEditor 二次开发的富文本编辑器

让人诟病的UI风格终于焕新了，还算在我的审美点上了，简单评测一下

优点：

缺点：

试用了1天，总给我不踏实的感觉，担心某一天又不维护了

编辑器的功能体验不是很好，有些功能是为了功能而功能，真心希望提升一下用户体验

Summernote

一款韩国人做的开源编辑器。基于 jQuery 和 Bootstrap 构建,支持快捷键操作,提供大量可定制的选项，乍一看，页面挺清新简洁的。但使用下来非常让人之气愤。用户提的bug和优化项目完全不理，格式化也是做的很差劲。搞不懂11k的star是怎么出来的

不推荐用。除非你喜欢用hook去擦屁股

lexical

Facebook出品的编辑器，大厂出品，值得信赖。

lexical是draft-js的升级版。由于draft-js只作维护，不做开发。整体功能已迁移到Lexical新框架。

github这样写道：

该项目目前处于维护模式。它不会收到任何功能更新，只会收到关键的安全漏洞补丁。2022 年 12 月 31 日，该仓库将完全归档。

对于寻找开源替代方案的用户，Meta 一直致力于迁移到一个名为Lexical的新框架。它仍处于实验阶段，我们正在努力添加迁移指南，但我们相信，它提供了一种更高效、更易于访问的替代方案。

样式见上图，很清爽，很漂亮。多而不乱，我蛮喜欢的。

功能上也很强大，图片拖拽、表格拖拽、导入导出，分享，还能进行涂鸦，绘图。还可以选中文本设置文本样式，同时还能对文本进行评论...功能上没得说，由于React是 Facebook的亲儿子，lexical也是基于React的编辑器 。虽然可以在vue上用，但官方支持主要集中在 React 上，因此在 Vue 中的集成需要额外处理一些兼容性问题。违背了我们选择不依赖框架语言的初衷。因此将lexical放在最后，不做过多的评价，也不会放在简评中。只是让我们多了解一下，尤其是React用户，可以作为备选方案

但要注意：Lexical 不支持 Internet Explorer 或旧版本的 Edge。需要兼容IE以及Edge浏览器的业务就不要选了

Facebook出品，可以作为React全家桶使用

简评

强烈推荐

Tinymce: 不知道怎么去选的时候，就用Tinymce！不求有功，但求无过

CKEditor: 文档格式化内容众多，追求使用效率，并且土豪公司或者人民币玩家就用它

Tiptap: 喜欢diy样式的，追求美观和别具一格的开发者首选

Jodit: 一次性付款，你值得拥有

比较推荐

Quill: 集成简单，小项目够用，大项目不推荐

wangEditor: 国人之光

wangEditor-next: wangEditor的升级版，持续迭代，持续为您服务

Editor: 存储，解析JSON数据的首选，其他慎选

Slate: 很棒的架构设计，期待早上发布

UEditor Plus: 基于 UEditor 二次开发的富文本编辑器，UI和功能都做了升级，初步体验还是蛮不错的，个人建议还是要慎用

不推荐

UEditor: 百度的烂尾项目，不够打了

Squire: 轻量级编辑器，格式文本还是可以的

Summernote: 韩国佬开发的项目，大爷级别的，反人类，还不搭理你

medium-editor 除了在文档上方显示，找不到其他的优点

总结

优秀的富文本编辑器不仅要页面美观，而且要格式化功能强大，使用方便快捷。非技术用户也能轻松排版、编辑、上传多媒体内容，从而提升管理平台的整体易用性和用户体验。因此，选择合适的富文本编辑器，不仅关系到内容生产的效率，更直接影响到平台的用户满意度和运营效果。

同时，我们也要认识到，不可能有一个编辑器能百分百满足我们的需求，理解开发富文本编辑器是一个巨难，且很难盈利的项目。只能尽可能的满足我们的痛点，在使用体验和需求功能上找到一个平衡点，权衡选择。

最后，祝开发找到适合自己公司的编辑器，早日脱坑

参考资料

大家好，我是徐徐。今天我们来认识认识 Electron。

前言

其实一直想系统的写一写 Electron 相关的文章，之前在掘金上写过，但是现在来看那些文章都写得挺粗糙的，所以现在我决定系统整理相关的知识，输出自己更多 Electron 开发相关的经验。这一节我们主要是来认识一下 Electron，这个已经有 10 年历史的跨端开发框架。我将从诞生背景，优劣势，生态，案例以及和其他框架的对比这几个方面带大家来认识 Electron。

Electron 诞生背景

Electron 的背景还是很强劲的，下面我们就来看看它是如何诞生的。

起源

Electron 的前身 Atom Shell，由 GitHub 的开发者在 2013 年创建的，当时 Atom 需要一个能够在桌面环境中运行的跨平台框架，同时能够利用 web 技术构建现代化的用户界面，于是就有了 Electron 的雏形。

需求 & Web 技术的发展

互联网的兴起使得桌面端的需求日益增长，传统的桌面应用开发需要针对每个操作系统（Windows、macOS、Linux）分别编写代码，这增加了开发和维护成本，所以非常需要可以通过一次开发实现多平台支持的框架。

随着 HTML5、CSS3 和 JavaScript 的快速发展，web 技术变得越来越强大和灵活。开发者希望能够利用这些技术构建现代化的用户界面，并且享受 web 开发工具和框架带来的便利。这使得更加需要一款跨端大杀器架来支持开发者，Electron 应运而生。

发展历程

• 2013 年：Atom Shell 诞生，最初用于 GitHub 的 Atom 编辑器。


• 2014 年 2 月：Atom 编辑器对外发布，Atom Shell 作为其核心技术。


• 2015 年 4 月：Atom Shell 更名为 Electron，并作为一个独立项目发布。随着时间的推移，Electron 的功能和社区支持不断增强。


• 2016 年：Electron 的应用开始广泛传播，许多公司和开发者开始使用 Electron 构建跨平台桌面应用。


• 2020 年：Electron 发布 10.0 版本，进一步增强了稳定性和性能。


• 2023 年：Electron 10 周年

更多可以参考：

http://www.electronjs.org/blog/electr…

Electron 优势

Electron 的优势非常的明显，大概总结为下面四个方面。

跨平台支持

Electron 的最大优势在于其跨平台特性。开发者可以编写一次代码，Electron 会处理不同操作系统之间的差异，使应用能够在 Windows、macOS 和 Linux 上无缝运行。

前端技术栈

Electron 应用使用 HTML、CSS 和 JavaScript 构建界面。开发者可以使用流行的前端框架和工具（如 React、Vue.js、Angular）来开发应用，提高开发效率和代码质量。

Node.js 集成

Electron 将 Chromium 和 Node.js 集成在一起，这使得应用不仅可以使用 web 技术构建界面，还可以使用 Node.js 访问底层系统资源，如文件系统、网络、进程等。

强大社区

Electron 拥有丰富的文档、教程、示例和强大的社区支持。开发者可以很容易地找到解决问题的方法和最佳实践，从而加快开发速度。

Electron 劣势

当然，一个东西都有两面性，有优势肯定也有劣势，劣势大概总结为以下几个方面。

性能问题

Electron 应用由于需要运行一个完整的 Chromium 实例，通常会占用较高的内存和 CPU 资源，性能相对较差。这在资源有限的设备上（如老旧计算机）尤为明显。

打包体积大

由于需要包含 Chromium 和 Node.js 运行时，Electron 应用的打包体积较大。一个简单的 Electron 应用的打包体积可能达到几十到上百 MB，这对于一些应用场景来说是不小的负担。

安全性

Electron 应用需要处理 web 技术带来的安全问题，如跨站脚本（XSS）攻击和远程代码执行（RCE）漏洞。开发者需要特别注意安全性，采取适当的防护措施（如使用 contextIsolation、sandbox、Content Security Policy 等）。

生态

上面谈到了 Electron 的优势和劣势，下面我们来看看 Electron 的生态。对于一款开源框架，生态是非常关键的，社区活跃度以及相应的配套工具非常影响框架的生态，如果有众多的开发者支持和维护这个框架，那么它的生态才会越来越好。Electron 的生态依托于 Node.js 发展出了很多很多开源工具，其生态是相当的繁荣。下面可以看看两张图就知道其生态的繁荣之处。

• GitHub 情况

• NPM 情况

下面是一些常见的相关生态工具。

打包和分发工具

• electron-packager：用于将 Electron 应用打包成可执行文件。支持多平台打包，简单易用。


• electron-builder：一个功能强大的打包工具，支持自动更新、多平台打包和安装程序制作。

测试工具

• Spectron：基于 WebDriver，用于 Electron 应用的端到端测试。支持模拟用户操作和验证应用行为。


• electron-mocha：用于在 Electron 环境中运行 Mocha 测试，适合进行单元测试和集成测试。

开发工具

• Electron Forge：一个集成开发工具，简化了 Electron 应用的开发、打包和分发流程。支持脚手架、插件系统和自动更新。


• Electron DevTools：调试和分析 Electron 应用性能的工具，帮助开发者优化应用性能。

案例

用 Electron开发的软件非常多，国内外都有很多知名的软件，有了成功的案例才会吸引更多的开发者使用它，下面是一些举例。

国内

• QQ


• 微信开发者工具


• 百度网盘


• 语雀


• 网易灵犀办公


• 网易云音乐

国外

• Visual Studio Code


• Slack


• Discord


• GitHub Desktop


• Postman


• WhatsApp

其他更多可参考：http://www.electronjs.org/apps

一个小技巧，Mac 电脑检测应用是否是 Electron 框架，在命令行运行如下代码：

for app in /Applications/*; do;[ -d  $app/Contents/Frameworks/Electron\ Framework.framework ] && echo $app; done

和其他跨端框架的对比

一个框架的诞生避免不了与同类型的框架对比，下面是一个对比表格，展示了 Electron 与其他流行的跨端桌面应用开发框架（如 NW.js、Proton Native、Tauri 和 Flutter Desktop）的优缺点和特性：

结语

Electron 是一个强大的跨平台开发框架，其诞生对前端开发者的意义非常大，让很多从事前端的开发者也有机会开发桌面客户端，扩大了前端开发工程师的岗位需求。当然，它不一定是最好的框架，因为适合自己的才是最好的，主要还是看自己的业务场景和技术需要，优势和劣势都是需要考虑的，仁者见仁，智者见智。

【新智元导读】Llama 4 本该是 AI 圈的焦点，却成了大型翻车现场。开源首日，全网实测代码能力崩盘。更让人震惊的是，模型训练测试集被曝作弊，内部员工直接请辞。

Meta 前脚刚发 Llama 4，后脚就有大佬请辞了！

一亩三分地的爆料贴称，经过反复训练后，Llama 4 未能取得 SOTA，甚至与顶尖大模型实力悬殊。

为了蒙混过关，高层甚至建议：

在后训练阶段中，将多个 benchmark 测试集混入训练数据。

在后训练阶段中，将多个 benchmark 测试集混入训练数据。

最终目的，让模型短期提升指标，拿出来可以看起来不错的结果。

这位内部员工 @dliudliu 表示，「自己根本无法接受这种做法，甚至辞职信中明确要求——不要在 Llama 4 技术报告中挂名」。

另一方面，小扎给全员下了「死令」——4 月底是 Llama 4 交付最后期限。

在一系列高压之下，已有高管提出了辞职。

其实，Llama 4 昨天开源之后，并没有在业内得到好评。全网测试中，代码能力极差，实力不如 GPT-4o。

网友 Flavio Adamo 使用相同的提示词，分别让 Llama 4 Maveric 和 GPT-4o 制作一个旋转多边形的动画。

可以看出，Llama 4 Maveric 生成的多边形并不规则而且没有开口。小球也不符合物理规律，直接穿过多边形掉下去了。

相比之下 GPT-4o 制作的动画虽然也不完美，但至少要好得多。

甚至，有人直接曝出，Llama 4 在 LMarena 上存在过拟合现象，有极大的「作弊」嫌疑。

而如今，内部员工爆料，进一步证实了网友的猜想。

沃顿商学院教授 Ethan Mollick 一语中的，「如果你经常使用 AI 模型，不难分辨出哪些是针对基准测试进行优化的，哪些是真正的重大进步」。

不过，另一位内部员工称，并没有遇到这类情况，不如让子弹飞一会儿。

内部员工爆料，Llama 4 训练作弊？

几位 AI 研究人员在社交媒体上都「吐槽」同一个问题，Meta 在其公告中提到 LM Arena 上的 Maverick 是一个「实验性的聊天版本」。

如果看得仔细一点，在 Llama 官网的性能对比测试图的最下面一行，写着「Llama 4 Maverick optimized for conversationality.」

翻译过来就是「针对对话优化的 Llama 4 Maverick」——似乎有些「鸡贼」。

这种「区别对待」的会让开发人员很难准确预测该模型在特定上下文中的表现。

AI 的研究人员观察到可公开下载的 Maverick 与 LM Arena 上托管的模型在行为上存在显著差异。

而就在今天上午，已经有人爆料 Llama 4 的训练过程存在严重问题！

即 Llama 4 内部训练多次仍然没有达到开源 SOTA 基准。

Meta 的领导层决定在后训练过程中混合各种基准测试集——让 Llama 4「背题」以期望在测试中取得「好成绩」。

这个爆料的原始来源是「一亩三分地」，根据对话，爆料者很可能来自于 Meta 公司内部。

对话中提到的 Meta AI 研究部副总裁 Joelle Pineau 也申请了 5 月底辞职。（不过，也有网友称并非是与 Llama4 相关）

但是根据 Meta 的组织架构体系，Pineau 是 FAIR 的副总裁，而 FAIR 实际上是 Meta 内部与 GenAI 完全独立的组织，GenAI 才是负责 Llama 项目的组织。

GenAI 的副总裁是 Ahmad Al-Dahle，他并没有辞职。

Llama 4 才刚刚发布一天，就出现如此重磅的消息，让未来显得扑朔迷离。

代码翻车，网友大失所望

在昨天网友的实测中，评论还是有好有坏。

但是过去一天进行更多的测试后，更多的网友表达了对 Llama 4 的不满。

在 Dr_Karminski 的一篇热帖中，他说 Llama-4-Maverick——总参数 402B 的模型——在编码能力方面大致只能与 Qwen-QwQ-32B 相当。

Llama-4-Scout——总参数 109B 的模型——大概与 Grok-2 或 Ernie 4.5 类似。

在评论中，网友响应了这个判断。

有人说 Llama 4 的表现比 Gemma 3 27B 还要差。

有人认为 Llama 4 的表现甚至和 Llama 3.2 一样没有任何进步，也无法完成写诗。

其他用户在测试后也表达了同样的观点，Llama 4 有点不符合预期。

网友 Deedy 也表达了对 Llama 4 的失望，称其为「一个糟糕的编程模型」。

他表示，Scout (109B) 和 Maverick (402B) 在针对编程任务的 Kscores 基准测试中表现不如 4o、Gemini Flash、Grok 3、DeepSeek V3 和 Sonnet 3.5/7。

他还给出了贴出了 Llama 4 两个模型的一张测试排名，结果显示这两个新发布的模型远远没有达到顶尖的性能。

网友 anton 说，Llama 4「真的有点令人失望」。

他表示自己不会用它来辅助编码，而 Llama 4 的定位有点尴尬。

anton 认为 Llama 4 的两个模型太大了，不太好本地部署。他建议 Meta 应该推出性能优秀的小模型，而不是去追求成为 SOTA。

「因为目前他们根本做不到。」他写道。

参考资料：

x.com/natolambert…

x.com/karminski3/…

x.com/abacaj/stat…

URL 结尾是否带 / 主要影响的是 服务器如何解析请求 以及 相对路径的解析方式，具体区别如下：

1. 基础概念