背景：

最近开始尝试做自媒体，录点视频。刚开始就遇到了字幕的问题，于是想先搞个字幕生成工具（为了这点醋才包的这顿饺子😄）：SubGen。

这个工具用 Tauri + Rust 做外壳，把 FFmpeg 和 Whisper.cpp 集成进去，能一键把视频转成 SRT 字幕。

这篇文章记录下笔者做这个工具的过程，也分享下用到的核心组件和代码结构。

架构设计

SubGen 采用分层架构，核心组件的交互关系如下：

┌─────────────┐        ┌──────────────┐

│   React UI  │        │   Rust Core  │

│ (TypeScript)│ <----> │  (Tauri API) │

└─────────────┘        └─────┬────────┘

                              │

                ┌─────────────┴───────────────┐

                │                             │

           ┌────▼────┐                   ┌────▼────┐

           │ FFmpeg  │                   │Whisper  │

           │ 提取音频 │                   │ 离线识别 │

           └─────────┘                   └─────────┘

为什么用 Tauri？

最开始笔者也考虑过 Electron，但它打包太大了（动辄 100MB 起步），而且资源占用高。后来发现 Tauri，它用 Rust 做后端，前端还是用 React 或者任意 Web 技术，这样：

• 打包后体积很小（十几 MB）。


• 跨平台方便（Windows / macOS / Linux）。


• Rust 调用本地二进制（FFmpeg 和 Whisper）非常顺手。

笔者主要是用 React + TypeScript 写了一个简单的 UI，用户选视频、点按钮，剩下的活就交给 Rust。

FFmpeg：用它来“扒”音频

FFmpeg 是老牌的音视频处理工具了，笔者直接内置了一个编译好的 ffmpeg.exe/ffmpeg 到资源目录，调用它来：

Rust 这边的调用很简单：

use std::process::Command;



Command::new("resources/ffmpeg")

    .args(["-i", &video_path, "-ar", "16000", "-ac", "1", "audio.wav"])

    .status()

    .expect("FFmpeg 执行失败");

这样一行命令就能把视频转成标准 WAV。

Whisper.cpp：核心的离线识别

笔者选的是 Whisper.cpp，因为它比 Python 版 Whisper 更轻量，直接编译一个 whisper-cli 就能用，不需要装乱七八糟的依赖。

更重要的一点是支持CPU运行，默认4个线程，即使用 ggml-large-v3 也可以跑出来结果，只是稍微慢点。这对于没有好的显卡的童鞋很有用！

调用命令大概是这样：

whisper-cli -m ggml-small.bin -f audio.wav -osrt -otxt

最后会输出一个 output.srt，直接能用。

Rust 里调用也是 Command::new() 一把梭：

Command::new("resources/whisper-cli")

    .args(["-m", "resources/models/ggml-small.bin", "-f", "audio.wav", "-l", "zh", "--output-srt"])

    .status()

    .expect("Whisper 执行失败");

代码结构和流程

笔者的项目大概是这样分层的：

subgen/

├── src/                     # 前端 React + TypeScript

│   └── main.tsx             # UI入口

├── src-tauri/               # Tauri + Rust

│   ├── commands.rs          # Rust命令逻辑

│   ├── resources/           # ffmpeg、whisper二进制、模型文件

│   └── main.rs              # 程序入口

前端用 @tauri-apps/api 的 invoke 调 Rust：

import { invoke } from '@tauri-apps/api';



async function handleGenerate(videoPath: string) {

  const result = await invoke<string>('extract_subtitles', { videoPath });

  console.log('字幕生成完成：', result);

}

Rust 后端的核心命令：

#[tauri::command]

fn extract_subtitles(video_path: String) -> Result<String, String> {

    // 1. 调 FFmpeg

    // 2. 调 Whisper.cpp

    // 3. 返回 SRT 路径

    Ok("output.srt".to_string())

}

用下来的感受

整个工具现在已经能做到“拖进视频 → 等几十秒 → 出字幕”这种体验了。

几个感受：

• Tauri 真香：比 Electron 清爽太多，Rust 后端很适合做这些底层调用。


• FFmpeg 是万能的，直接抽音频，性能还不错。


• Whisper.cpp 虽然 CPU 跑慢点，但好在准确率挺高，还不用联网。

后续想做的事

• 支持批量处理视频。


• 集成一个简单的字幕编辑功能。


• 尝试 GPU 加速 Whisper（Metal / Vulkan）。

截图

主界面：

生成的 SRT：

如果你也想做个自己的字幕工具，可以直接参考 SubGen 的架构，自己改改就能用。

代码已开源：github.com/byteroycai/…

jwt，过滤器，拦截器介绍

JWT令牌

JWT介绍

JWT全称 JSON Web Token 。

jwt可以将原始的json数据格式进行安全的封装，这样就可以直接基于jwt在通信双方安全的进行信息传输了。

JWT的组成

JWT令牌由三个部分组成，三个部分之间使用英文的点来分割

• 第一部分：Header(头）， 记录令牌类型、签名算法等。 例如：{"alg":"HS256","type":"JWT"}
• 第二部分：Payload(有效载荷），携带一些自定义信息、默认信息等。 例如：{"id":"1","username":"Tom"}
• 第三部分：Signature(签名），防止Token被篡改、确保安全性。将header、payload，并加入指定秘钥，通过指定签名算法计算而来。

JWT将原始的JSON格式数据转变为字符串的方式：

• 其实在生成JWT令牌时，会对JSON格式的数据进行一次编码：进行base64编码
• Base64：是一种基于64个可打印的字符来表示二进制数据的编码方式。既然能编码，那也就意味着也能解码。所使用的64个字符分别是A到Z、a到z、 0- 9，一个加号，一个斜杠，加起来就是64个字符。任何数据经过base64编码之后，最终就会通过这64个字符来表示。当然还有一个符号，那就是等号。等号它是一个补位的符号
• 需要注意的是Base64是编码方式，而不是加密方式。

生成和校验

1.要想使用JWT令牌，需要先引入JWT的依赖：

<dependency>

    <groupId>io.jsonwebtokengroupId>

    <artifactId>jjwtartifactId>

    <version>0.9.1version>

dependency>

引入完JWT来赖后，就可以调用工具包中提供的API来完成JWT令牌的生成和校验。

2.生成JWT代码实现：

@Test

public void testGenJwt() {

    Map<String, Object> claims = new HashMap<>();

    claims.put("id", 10);

    claims.put("username", "itheima");



    String jwt = Jwts.builder().signWith(SignatureAlgorithm.HS256, "aXRjYXN0")

        .addClaims(claims)

        .setExpiration(new Date(System.currentTimeMillis() + 12 * 3600 * 1000))

        .compact();



    System.out.println(jwt);

}

3. 实现了JWT令牌的生成，下面我们接着使用Java代码来校验JWT令牌(解析生成的令牌)：

@Test

public void testParseJwt() {

    Claims claims = Jwts.parser().setSigningKey("aXRjYXN0")

        .parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MTAsInVzZXJuYW1lIjoiaXRoZWltYSIsImV4cCI6MTcwMTkwOTAxNX0.N-MD6DmoeIIY5lB5z73UFLN9u7veppx1K5_N_jS9Yko")

        .getBody();

    System.out.println(claims);

}

篡改令牌中的任何一个字符，在对令牌进行解析时都会报错，所以JWT令牌是非常安全可靠的。

JWT令牌过期后，令牌就失效了，解析的为非法令牌。

过滤器Filter

Filter介绍

• Filter表示过滤器，是 JavaWeb三大组件(Servlet、Filter、Listener)之一。
• 过滤器可以把对资源的请求拦截下来，从而实现一些特殊的功能
  • 使用了过滤器之后，要想访问web服务器上的资源，必须先经过滤器，过滤器处理完毕之后，才可以访问对应的资源。
• 过滤器一般完成一些通用的操作，比如：登录校验、统一编码处理、敏感字符处理等。

定义过滤器

public class DemoFilter implements Filter {

    //初始化方法, web服务器启动, 创建Filter实例时调用, 只调用一次

    public void init(FilterConfig filterConfig) throws ServletException {

        System.out.println("init ...");

    }



    //拦截到请求时,调用该方法,可以调用多次

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {

        System.out.println("拦截到了请求...");

    }



    //销毁方法, web服务器关闭时调用, 只调用一次

    public void destroy() {

        System.out.println("destroy ... ");

    }

}

配置过滤器

在定义完Filter之后，Filter其实并不会生效，还需要完成Filter的配置，Filter的配置非常简单，只需要在Filter类上添加一个注解：@WebFilter，并指定属性urlPatterns，通过这个属性指定过滤器要拦截哪些请求

@WebFilter(urlPatterns = "/*") //配置过滤器要拦截的请求路径（ /* 表示拦截浏览器的所有请求 ）

public class DemoFilter implements Filter {

    //初始化方法, web服务器启动, 创建Filter实例时调用, 只调用一次

    public void init(FilterConfig filterConfig) throws ServletException {

        System.out.println("init ...");

    }



    //拦截到请求时,调用该方法,可以调用多次

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException {

        System.out.println("拦截到了请求...");

    }



    //销毁方法, web服务器关闭时调用, 只调用一次

    public void destroy() {

        System.out.println("destroy ... ");

    }

}

在Filter类上面加了@WebFilter注解之后，还需要在启动类上面加上一个注解@ServletComponentScan，通过这个@ServletComponentScan注解来开启SpringBoot项目对于Servlet组件的支持。

@ServletComponentScan //开启对Servlet组件的支持

@SpringBootApplication

public class TliasManagementApplication {

    public static void main(String[] args) {

        SpringApplication.run(TliasManagementApplication.class, args);

    }

}

在过滤器Filter中，如果不执行放行操作，将无法访问后面的资源。 放行操作：chain.doFilter(request, response);

过滤器的执行流程

过滤器当中我们拦截到了请求之后，如果希望继续访问后面的web资源，就要执行放行操作，放行就是调用 FilterChain对象当中的doFilter()方法，在调用doFilter()这个方法之前所编写的代码属于放行之前的逻辑。

测试代码：

@WebFilter(urlPatterns = "/*") 

public class DemoFilter implements Filter {

    

    @Override //初始化方法, 只调用一次

    public void init(FilterConfig filterConfig) throws ServletException {

        System.out.println("init 初始化方法执行了");

    }

    

    @Override

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

        

        System.out.println("DemoFilter   放行前逻辑.....");



        //放行请求

        filterChain.doFilter(servletRequest,servletResponse);



        System.out.println("DemoFilter   放行后逻辑.....");

        

    }



    @Override //销毁方法, 只调用一次

    public void destroy() {

        System.out.println("destroy 销毁方法执行了");

    }

}

过滤器的拦截路径配置

拦截路径	urlPatterns值	含义
拦截具体路径	/login	只有访问 /login 路径时，才会被拦截
目录拦截	/emps/*	访问/emps下的所有资源，都会被拦截
拦截所有	/*	访问所有资源，都会被拦截

测试代码：

@WebFilter(urlPatterns = "/login")  //拦截/login具体路径

public class DemoFilter implements Filter {

    @Override

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

        System.out.println("DemoFilter   放行前逻辑.....");



        //放行请求

        filterChain.doFilter(servletRequest,servletResponse);



        System.out.println("DemoFilter   放行后逻辑.....");

    }





    @Override

    public void init(FilterConfig filterConfig) throws ServletException {

        Filter.super.init(filterConfig);

    }



    @Override

    public void destroy() {

        Filter.super.destroy();

    }

}

过滤器链

过滤器链指的是在一个web应用程序当中，可以配置多个过滤器，多个过滤器就形成了一个过滤器链。

过滤器链上过滤器的执行顺序：注解配置的Filter，优先级是按照过滤器类名（字符串）的自然排序。 比如：

• AbcFilter
• DemoFilter

这两个过滤器来说，AbcFilter 会先执行，DemoFilter会后执行。

拦截器Interceptor

• 拦截器是一种动态拦截方法调用的机制，类似于过滤器。
• 拦截器是Spring框架中提供的，用来动态拦截控制器方法的执行。
• 拦截器的作用：拦截请求，在指定方法调用前后，根据业务需要执行预先设定的代码。

自定义拦截器

实现HandlerInterceptor接口，并重写其所有方法

//自定义拦截器

@Component

public class DemoInterceptor implements HandlerInterceptor {

    //目标资源方法执行前执行。 返回true：放行    返回false：不放行

    @Override

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

        System.out.println("preHandle .... ");

        

        return true; //true表示放行

    }



    //目标资源方法执行后执行

    @Override

    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {

        System.out.println("postHandle ... ");

    }



    //视图渲染完毕后执行，最后执行

    @Override

    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

        System.out.println("afterCompletion .... ");

    }

}

• preHandle方法：目标资源方法执行前执行。 返回true：放行 返回false：不放行
• postHandle方法：目标资源方法执行后执行
• afterCompletion方法：视图渲染完毕后执行，最后执行

注册配置拦截器

在 com.itheima下创建一个包，然后创建一个配置类 WebConfig， 实现 WebMvcConfigurer 接口，并重写 addInterceptors 方法

@Configuration  

public class WebConfig implements WebMvcConfigurer {



    //自定义的拦截器对象

    @Autowired

    private DemoInterceptor demoInterceptor;



    

    @Override

    public void addInterceptors(InterceptorRegistry registry) {

       //注册自定义拦截器对象

        registry.addInterceptor(demoInterceptor).addPathPatterns("/**");//设置拦截器拦截的请求路径（ /** 表示拦截所有请求）

    }

}

拦截器的拦截路径配置

首先我们先来看拦截器的拦截路径的配置，在注册配置拦截器的时候，我们要指定拦截器的拦截路径，通过addPathPatterns("要拦截路径")方法，就可以指定要拦截哪些资源。

在入门程序中我们配置的是/**，表示拦截所有资源，而在配置拦截器时，不仅可以指定要拦截哪些资源，还可以指定不拦截哪些资源，只需要调用excludePathPatterns("不拦截路径")方法，指定哪些资源不需要拦截。

@Configuration  

public class WebConfig implements WebMvcConfigurer {



    //拦截器对象

    @Autowired

    private DemoInterceptor demoInterceptor;



    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        //注册自定义拦截器对象

        registry.addInterceptor(demoInterceptor)

                .addPathPatterns("/**")//设置拦截器拦截的请求路径（ /** 表示拦截所有请求）

                .excludePathPatterns("/login");//设置不拦截的请求路径

    }

}

在拦截器中除了可以设置/**拦截所有资源外，还有一些常见拦截路径设置：

拦截路径	含义	举例
/*	一级路径	能匹配/depts，/emps，/login，不能匹配 /depts/1
/**	任意级路径	能匹配/depts，/depts/1，/depts/1/2
/depts/*	/depts下的一级路径	能匹配/depts/1，不能匹配/depts/1/2，/depts
/depts/**	/depts下的任意级路径	能匹配/depts，/depts/1，/depts/1/2，不能匹配/emps/1

拦截器的执行流程

• 当我们打开浏览器来访问部署在web服务器当中的web应用时，此时我们所定义的过滤器会拦截到这次请求。拦截到这次请求之后，它会先执行放行前的逻辑，然后再执行放行操作。而由于我们当前是基于springboot开发的，所以放行之后是进入到了spring的环境当中，也就是要来访问我们所定义的controller当中的接口方法。
• Tomcat并不识别所编写的Controller程序，但是它识别Servlet程序，所以在Spring的Web环境中提供了一个非常核心的Servlet：DispatcherServlet（前端控制器），所有请求都会先进行到DispatcherServlet，再将请求转给Controller。
• 当我们定义了拦截器后，会在执行Controller的方法之前，请求被拦截器拦截住。执行preHandle()方法，这个方法执行完成后需要返回一个布尔类型的值，如果返回true，就表示放行本次操作，才会继续访问controller中的方法；如果返回false，则不会放行（controller中的方法也不会执行）。
• 在controller当中的方法执行完毕之后，再回过来执行postHandle()这个方法以及afterCompletion() 方法，然后再返回给DispatcherServlet，最终再来执行过滤器当中放行后的这一部分逻辑的逻辑。执行完毕之后，最终给浏览器响应数据。

过滤器和拦截器之间的区别：

• 接口规范不同：过滤器需要实现Filter接口，而拦截器需要实现HandlerInterceptor接口。
• 拦截范围不同：过滤器Filter会拦截所有的资源，而Interceptor只会拦截Spring环境中的资源。

作者：丧心病狂汤姆猫
来源：juejin.cn/post/7527869985345339392

当你在浏览器里输入 http://www.example.com 并按下回车，看似平平无奇的一次访问，其实暗藏着 SSL/TLS 的三次握手、对称与非对称加密的轮番上阵、CA 证书的“身份核验”以及防中间人攻击的多重机关。

一、SSL、TLS、HTTPS 到底是什么关系？

• SSL（Secure Sockets Layer）：早期网景公司设计的加密协议，1999 年后停止更新。


• TLS（Transport Layer Security）：SSL 的直系升级版，目前主流版本为 TLS 1.2/1.3。


• HTTPS：把 HTTP 报文塞进 TLS 的“安全信封”里，再交给 TCP 传输。简而言之，HTTPS = HTTP + TLS/SSL。

二、HTTPS 握手

三、为什么必须有 CA？

没有 CA，任何人都可以伪造公钥，中间人攻击将防不胜防。CA 通过可信第三方背书，把“公钥属于谁”这件事写死在证书里，浏览器才能放心地相信“这就是真正的服务器”。

四、证书到底怎么防伪？

证书 = 域名 + 公钥 + 有效期 + CA 数字签名。

CA（Certificate Authority）用自己的私钥对整个证书做哈希签名。浏览器内置 CA 公钥，可解密签名并对比哈希值，一旦被篡改就立即报警。

没有 CA 签名的自签证书？浏览器会毫不留情地显示“红色警告”。

五、对称与非对称加密的分工

• 非对称加密（RSA/ECC）：只在握手阶段用一次，解决“如何安全地交换对称密钥”。


• 对称加密（AES/ChaCha20）：握手完成后，所有 HTTP 报文都用对称密钥加解密，性能高、延迟低。

一句话：非对称加密“送钥匙”，对称加密“锁大门”。

六、中间人攻击的两张面孔

总结

下次当你在地址栏看到那把绿色小锁时，背后是一场涉及四次握手、两把密钥、一张证书和全球信任链的加密大戏。

想让网页上的图片、视频或者整个界面铺满用户屏幕？浏览器的 requestFullscreen api 是开发者实现这个功能的关键。

它比你想象的要强大，但也藏着一些需要注意的细节。本文将详细介绍如何正确使用它，并分享一些提升用户体验的实用技巧。

一、 开始使用 requestFullscreen：基础与常见问题

直接调用 element.requestFullscreen() 是最简单的方法，但有几个关键点容易出错：

并非所有元素都能直接全屏：

/* 为处于全屏状态的 <video> 元素设置黑色背景 */

video:fullscreen {

background-color: #000;

}



/* 当某个具有 id="controls" 的元素在全屏模式下时，默认半透明，鼠标移上去变清晰 */

#controls:fullscreen {

opacity: 0.3;

transition: opacity 0.3s ease;

}

#controls:fullscreen:hover {

opacity: 1;

}

const fullscreenManager = {

currentElement: null, // 记录当前全屏的元素



async toggle(element) {

// 如果点击的元素已经是全屏元素，则退出全屏

if (document.fullscreenElement && this.currentElement === element) {

try {

awaitdocument.exitFullscreen();

this.currentElement = null;

      } catch (error) {

console.error('退出全屏失败:', error);

      }

    } else {

// 否则，尝试让新元素进入全屏

try {

await element.requestFullscreen();

this.currentElement = element; // 更新当前元素

      } catch (error) {

console.error('进入全屏失败:', error);

// 可以在这里提供一个后备方案，比如模拟全屏的CSS类

        element.classList.add('simulated-fullscreen');

      }

    }

  }

};



// 给图库中所有图片绑定点击事件

document.querySelectorAll('.gallery-img').forEach(img => {

  img.addEventListener('click', () => fullscreenManager.toggle(img));

});

functionhandleFullscreenHotkeys(event) {

// 保留 Escape 键退出全屏的功能

if (event.key === 'Escape') return;



// 自定义快捷键

if (event.key === 'f') toggleFilter(); // 按 F 切换滤镜

if (event.ctrlKey && event.key === 'p') enterPictureInPicture(); // Ctrl+P 画中画

if (event.shiftKey && event.key === 's') captureScreenshot(); // Shift+S 截图



// 阻止这些键的默认行为（比如防止F键触发浏览器查找）

event.preventDefault();

}



// 监听全屏状态变化

document.addEventListener('fullscreenchange', () => {

if (document.fullscreenElement) {

// 进入全屏，添加自定义键盘监听

document.addEventListener('keydown', handleFullscreenHotkeys);

  } else {

// 退出全屏，移除自定义键盘监听

document.removeEventListener('keydown', handleFullscreenHotkeys);

  }

});

// 页面加载完成后检查是否需要恢复全屏

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

  const elementId = localStorage.getItem('fullscreenElementId');

if (elementId) {

    const element = document.getElementById(elementId);

if (element) {

setTimeout(() => element.requestFullscreen().catch(console.error), 100); // 稍延迟确保元素就绪

    }

  }

});



// 监听全屏变化，保存当前全屏元素的ID

document.addEventListener('fullscreenchange', () => {

if (document.fullscreenElement) {

localStorage.setItem('fullscreenElementId', document.fullscreenElement.id);

  } else {

localStorage.removeItem('fullscreenElementId');

  }

});

<divid="main-container">

<iframeid="nested-content"src="inner.html"allow="fullscreen"></iframe>

</div>

<script>

const mainContainer = document.getElementById('main-container');

const iframe = document.getElementById('nested-content');



// 主容器全屏后，可以尝试触发iframe内部元素的全屏（需内部配合）

  mainContainer.addEventListener('fullscreenchange', () => {

if (document.fullscreenElement === mainContainer) {

// 假设iframe内部有一个id为'innerVideo'的视频元素

// 注意：这需要在iframe加载完成后，且iframe内容同源或允许跨域操作

const innerDoc = iframe.contentDocument || iframe.contentWindow.document;

const innerVideo = innerDoc.getElementById('innerVideo');

if (innerVideo) {

setTimeout(() => innerVideo.requestFullscreen().catch(console.error), 500);

      }

    }

  });

</script>

/**

 * 全屏工具类 (简化版，展示核心功能)

 */

const FullscreenHelper = {

/**

   * 请求元素进入全屏模式

   * @param {HTMLElement} [element=document.documentElement] 要全屏的元素，默认是整个页面

   * @returns {Promise<boolean>} 是否成功进入全屏

   */

async enter(element = document.documentElement) {

const reqMethods = [

'requestFullscreen',       // 标准

'webkitRequestFullscreen', // Safari, Old Chrome/Edge

'mozRequestFullScreen',    // Firefox

'msRequestFullscreen'// Old IE/Edge

    ];



for (const method of reqMethods) {

if (element[method]) {

try {

// 可以传递选项，例如隐藏导航UI: { navigationUI: 'hide' }

await element[method]({ navigationUI: 'hide' });

returntrue; // 成功进入全屏

        } catch (error) {

console.warn(`${method} 失败:`, error);

// 继续尝试下一个方法

        }

      }

    }

returnfalse; // 所有方法都失败

  },



/**

   * 退出全屏模式

   * @returns {Promise<boolean>} 是否成功退出全屏

   */

async exit() {

const exitMethods = [

'exitFullscreen',          // 标准

'webkitExitFullscreen',     // Safari, Old Chrome/Edge

'mozCancelFullScreen',      // Firefox

'msExitFullscreen'// Old IE/Edge

    ];



for (const method of exitMethods) {

if (document[method]) {

try {

awaitdocument[method]();

returntrue; // 成功退出全屏

        } catch (error) {

console.warn(`${method} 失败:`, error);

        }

      }

    }

returnfalse; // 所有方法都失败或不在全屏状态

  },



/**

   * 检查当前是否有元素处于全屏状态

   * @returns {boolean} 是否在全屏状态

   */

  isFullscreen() {

return !!(

document.fullscreenElement ||    // 标准

document.webkitFullscreenElement || // Safari, Old Chrome/Edge

document.mozFullScreenElement || // Firefox

document.msFullscreenElement     // Old IE/Edge

    );

  },



/**

   * 添加全屏状态变化监听器

   * @param {Function} callback 状态变化时触发的回调函数

   */

  onChange(callback) {

const events = [

'fullscreenchange',       // 标准

'webkitfullscreenchange', // Safari, Old Chrome/Edge

'mozfullscreenchange',    // Firefox

'MSFullscreenChange'// Old IE/Edge

    ];

// 为每种可能的事件添加监听，确保兼容性

    events.forEach(eventName => {

document.addEventListener(eventName, callback);

    });

  }

};



// 使用示例

const myButton = document.getElementById('fullscreen-btn');

const myVideo = document.getElementById('my-video');



myButton.addEventListener('click', async () => {

if (FullscreenHelper.isFullscreen()) {

await FullscreenHelper.exit();

  } else {

await FullscreenHelper.enter(myVideo); // 让视频全屏

  }

});



// 监听全屏变化

FullscreenHelper.onChange(() => {

console.log('全屏状态变了:', FullscreenHelper.isFullscreen() ? '进入全屏' : '退出全屏');

});

前言

在 JavaScript 开发者的日常中，这样的对话时常发生：

• 👨💻 新人："为什么页面突然白屏了？"


• 👨🔧 老人："异步请求没做错误处理吧？"

async/await 看似优雅的语法糖背后，隐藏着一个关键问题：错误处理策略的抉择。

在 JavaScript 中使用 async/await 时，很多人会问：“必须使用 try/catch 吗？”

其实答案并非绝对，而是取决于你如何设计错误处理策略和代码风格。

接下来，我们将探讨 async/await 的错误处理机制、使用 try/catch 的优势，以及其他可选的错误处理方法。

async/await 的基本原理

异步代码的进化史

// 回调地狱时代

fetchData(url1, (data1) => {

  process(data1, (result1) => {

    fetchData(url2, (data2) => {

      // 更多嵌套...

    })

  })

})



// Promise 时代

fetchData(url1)

  .then(process)

  .then(() => fetchData(url2))

  .catch(handleError)



// async/await 时代

async function workflow() {

  const data1 = await fetchData(url1)

  const result = await process(data1)

  return await fetchData(url2)

}

async/await 是基于 Promise 的语法糖，它使异步代码看起来更像同步代码，从而更易读、易写。一个 async 函数总是返回一个 Promise，你可以在该函数内部使用 await 来等待异步操作完成。

如果在异步操作中出现错误（例如网络请求失败），该错误会使 Promise 进入 rejected 状态。

async function fetchData() {

  const response = await fetch("https://api.example.com/data");

  const data = await response.json();

  return data;

}

使用 try/catch 捕获错误

打个比喻，就好比铁路信号系统

想象 async 函数是一列高速行驶的列车：

• await 是轨道切换器：控制代码执行流向


• 未捕获的错误如同脱轨事故：会沿着铁路网（调用栈）逆向传播


• try/catch 是智能防护系统：
  
  
  
  • 自动触发紧急制动（错误捕获）
  
  
  • 启动备用轨道（错误恢复逻辑）
  
  
  • 向调度中心发送警报（错误日志）
  
  
  
  

为了优雅地捕获 async/await 中出现的错误，通常我们会使用 try/catch 语句。这种方式可以在同一个代码块中捕获抛出的错误，使得错误处理逻辑更集中、直观。

• 代码逻辑集中，错误处理与业务逻辑紧密结合。


• 可以捕获多个 await 操作中抛出的错误。


• 适合需要在出错时进行统一处理或恢复操作的场景。

async function fetchData() {

  try {

    const response = await fetch("https://api.example.com/data");

    if (!response.ok) {

      throw new Error(`HTTP error! status: ${response.status}`);

    }

    const data = await response.json();

    return data;

  } catch (error) {

    console.error("Error fetching data:", error);

    // 根据需要，可以在此处处理错误，或者重新抛出以便上层捕获

    throw error;

  }

}

不使用 try/catch 的替代方案

虽然 try/catch 是最直观的错误处理方式，但你也可以不在 async 函数内部使用它，而是在调用该 async 函数时捕获错误。

在 Promise 链末尾添加 .catch()

async function fetchData() {

  const response = await fetch("https://api.example.com/data");

  if (!response.ok) {

    throw new Error(`HTTP error! status: ${response.status}`);

  }

  return response.json();

}



// 调用处使用 Promise.catch 捕获错误

fetchData()

  .then(data => {

    console.log("Data:", data);

  })

  .catch(error => {

    console.error("Error fetching data:", error);

  });

这种方式将错误处理逻辑移至函数调用方，适用于以下场景：

• 当多个调用者希望以不同方式处理错误时。


• 希望让 async 函数保持简洁，将错误处理交给全局统一的错误处理器（例如在 React 应用中可以使用 Error Boundary）。

将 await 与 catch 结合

async function fetchData() {

  const response = await fetch('https://api.example.com/data').catch(error => {

    console.error('Request failed:', error);

    return null; // 返回兜底值

  });

  if (!response) return;

  // 继续处理 response...

}

全局错误监听（慎用，适合兜底）

// 浏览器端全局监听

window.addEventListener('unhandledrejection', event => {

  event.preventDefault();

  sendErrorLog({

    type: 'UNHANDLED_REJECTION',

    error: event.reason,

    stack: event.reason.stack

  });

  showErrorToast('系统异常，请联系管理员');

});



// Node.js 进程管理

process.on('unhandledRejection', (reason, promise) => {

  logger.fatal('未处理的 Promise 拒绝:', reason);

  process.exitCode = 1;

});

错误处理策略矩阵

决策树分析

graph TD

  A[需要立即处理错误?] -->|是| B[使用 try/catch]

  A -->|否| C{错误类型}

  C -->|可恢复错误| D[Promise.catch]

  C -->|致命错误| E[全局监听]

  C -->|批量操作| F[Promise.allSettled]

错误处理体系

小结

我的观点是：不强制要求，但强烈推荐

• 不强制：如果不需要处理错误，可以不使用 try/catch，但未捕获的 Promise 拒绝（unhandled rejection）会导致程序崩溃（在 Node.js 或现代浏览器中）。


• 推荐：90% 的场景下需要捕获错误，因此 try/catch 是最直接的错误处理方式。

所有我个人观点：使用 async/await 尽量使用 try/catch。好的错误处理不是消灭错误，而是让系统具备优雅降级的能力。

你的代码应该像优秀的飞行员——在遇到气流时，仍能保持平稳飞行。大家如有不同意见，还请评论区讨论，说出自己的见解。

当功能开发完成dev 稳定后合并进 test，然后QA 回归测试环境；如发现问题，在 hotfix/xxx 修复后继续合并回 test（实际开发中，为了简化开发流程，大家都是直接在test修改bug）。

3. 预发布验证

测试通过，临近上线时，会从 test 合并进 pre。pre 仅用于业务验证、客户预览，不会在开发新功能；遇到bug的话，必须基于pre拉一个hotfix分支，修复完通过验证后，在合并回pre。

4. 正式上线

从 pre 合并到 prod ，并部署上线；

为什么不能直接在pre修改bug

pre 是预发布环境分支，作用是：模拟线上环境，确保代码上线前是可靠的，它应只接收已审核通过的改动，而不是“随便修的东西”。

如果直接在 pre 上修改，会出现很多意料之外的问题。如：

• 代码来源不清晰，审查流程被绕过
• 多人协作下容易引发冲突和覆盖（bug重现）

这样时间久了我们根本不知道哪个 bug 是从哪冒出来的，代码就会变得难以维护和溯源。

因此，基于pre拉一个hotfix/xxx 分支是团队开发的规范流程：

• 创建热修分支（hotfix 分支）

从 pre 分支上拉一个新的临时分支，命名建议规范些，如：

git checkout pre

git pull origin pre        # 确保是最新代码

git checkout -b hotfix/fix-button-not-working

• 2在 hotfix 分支中修复 bug

进行代码修改、调试、测试。

• 创建合并请求

bug修复且通过qa验证后，我们就可以合并至pre等待审核。

使用hotfix，大家一看到这个分支名字，大家就知道这是线上急修的问题，容易跟踪、回溯和管理。你直接在 pre 改，其他人甚至都不知道发生了 bug。

总结

通过本文，大家应该也进一步了解pre环境的bug处理规范，如果你还觉得小问题在pre直接修改问题不大，可以看看这个示例：

你是一个信誉良好的企业老板，你的样品准备提交客户的时候突然发现了问题。你正常的流程应该是：

• 回原材料工厂排查修理
• 重新打样
• 提交新样品
• 送给客户

除非你是黑心老板，样品有问题直接凑合修一下直接给客户。

表妹问：前端好玩吗？我说好玩，但表妹接下来的回复看哭了我。

是的，回复如下：

这红海血途上，新兵举着 "大前端" 旌旗冲锋，老兵拖着node_modules残躯撤退。资本织机永不停歇，框架版本更迭如暴君换季，留下满地deprecated警告如秋后落叶。

其一、夹缝中的苦力

世人都道前端易，不过调接口、改颜色，仿佛稚童搭积木。却不知那屏幕上寸寸像素之间，皆是血泪。产品拍案，需求朝夕三变，昨日之红蓝按钮，今晨便成黑白圆角。UI稿纸翻飞如雪，设计师手持“用户体验”四字大旗，将五更赶工的代码尽数碾碎。后端端坐高台，接口文档空悬如镜花水月，待到交付时辰，方抛来残缺数据。此时节，前端便成了那补天的女娲，于混沌中捏造虚拟对象，用JSON.parse('{"data": undefined}')这等荒诞戏法，将虚无粉饰成真实。

看这段代码何等悲凉：

// 后端曰：此接口返data字段，必不为空

fetch('api/data').then(res => {

  const { data } = res;

  render(data[0].children[3].value || '默认值'); // 层层掘墓，方见白骨

});

此乃前端日常——在数据废墟里刨食，用||与?.铸成铁锹，掘出三分体面。

其二、技术的枷锁

JavaScript本是脚本小儿，如今却要扛鼎江山。君不见React、Vue、Angular三座大山压顶，每年必有新神像立起。昨日方学得Redux真经，今朝GraphQL又成显学。更有Electron、ReactNative、Flutter诸般法器，教人左手写桌面应用，右手调移动端手势。所谓“大前端”，实乃资本画饼之术，人前跨端写，人后页面仔——既要马儿跑，又要马儿不吃草；以切图之名，许一份低劣薪水，行三五岗位之事。

且看这跨平台代码何等荒诞：

// 一套代码统治三界（iOS/Android/Web）

<View>

  {Platform.OS === 'web' ? 

    <div onClick={handleWebClick} /> : 

    <TouchableOpacity onPress={handleNativePress} />

  }

View>

此类缝合怪代码，恰似给长衫打补丁，既失体统，又损性能。待到内存泄漏、渲染卡顿时，众人皆指前端曰："此子学艺不精！"

何人怜悯前端 node18 react19 逐人老，后端写着 java8 看着 java22 笑。

其三、尊严的消亡

领导提拔，必先问尔可懂SpringBoot、MySQL分库分表？纵使前端用WebGL绘出三维宇宙，用WebAssembly重写操作系统，在会议室里仍是“做界面的”。工资单上数字最是直白——同司后端新人起薪万数，前端老将苦熬三年方摸得此数。更可笑者，产品经理醉酒时吐真言："你们不就是改改CSS么？"

再看这可视化代码何等心酸：

// 用Canvas画十万级数据点

ctx.beginPath();

dataPoints.forEach((point, i) => {

  if (i % 100 === 0) ctx.stroke(); // 分段渲染防卡死

  ctx.lineTo(point.x, point.y);

});

此等精密计算，在他人眼中不过"动画效果"，与美工修图无异。待浏览器崩溃，众人皆曰："定是前端代码劣质！"

技术大会，后端高谈微服务、分布式，高并发，满座掌声如雷，实则系统使用量百十来人也是远矣；前端言及 CSS 栅格、浏览器渲染，众人瞌睡连天。领导抚掌笑曰：“后端者，国之重器；前端者，雕虫小技。” 晋升名单，后端之名列如长蛇，前端者埋没于墙角尘埃。纵使将那界面写出花来，终是 “切图仔” 定终身。

其四、维护者的悲歌

JavaScript本无类型，如野马脱缰。若非经验老道之一，常写出这等代码：

function handleData(data) {

  if (data && typeof data === 'object') { // 万能判断

    return data.map(item => ({

      ...item,

      newProp: item.id * Math.random() // 魔改数据

    }));

  }

  return []; // 默认返回空阵，埋下百处报错

}

此类代码如瘟疫蔓延，领导却言“这些功能实习生也能写！”，却不顾三月后连作者亦不敢相认，只得下任前端难上加难。

而后端有Type大法，编译检查护体，有Swagger契约，有Docker容器，纵使代码如乱麻，只需扩内存、增实例，便可遮掩性能疮疤。

其五、末路者的自白

诸君且看这招聘启事："需精通Vue3+TS+Webpack，熟悉React/Node.js，有Electron/小程序经验，掌握Three.js/WebGL者重点考虑。" 薪资却标着"6-8K"。更有机智者发明"全栈"之名，实欲以一人之躯，承三头六臂之劳。

再看这面试题何等荒谬：

// 手写Promise实现A+规范

class MyPromise {

  // 三千行后，方知自己仍是蝼蚁

}

此等屠龙之术，入职后唯调API用。恰似逼庖丁解牛，却令其日日杀鸡。

或以使用组件库之经验薪资招之，又以写不好组件库之责裁出。

尾声：铁屋中的叩问

前端者，数字化时代的纺织工也。资本织机日夜轰鸣，框架如梭穿行不息。程序员眼底血丝如网。所谓"全栈工程师"，实为包身工雅称；所谓"技术革新"，不过剥削新法。

若仍有少年热血未冷，欲投身此业，且听我一言：君有凌云志，何不学Rust/C++，做那操作系统、数据库等真·屠龙技？莫要困在这CSS牢笼中，为圆角像素折腰，为虚无需求焚膏。前端之路，已是红海血途，望后来者三思，三思！

问题描述

昨天下班的时候，运营反馈了一个问题，明明设置的是两天后解封，为什么提示却是三天后呢。

比如今天(6.16)被拉入黑名单了，用户报名会提示 “6.19号恢复报名”，但是现在却提示6月20号才能报名，经过排查发现，就是解封的时间被多加了 1s 中，本来应该是存2025-06-18 23:59:59，但是数据库却是2025-06-19 00:00:00。

看了数据库有接近一半的数据是正确的，有一半的数据是第二天0晨（百思不得其解啊🤣）

代码逻辑实现：

LocalDateTime currentTime = LocalDateTime.now();

LocalDateTime futureTime = currentTime.plus(2, ChronoUnit.DAYS);

// 设置了为当天的最后一秒啊

LocalDateTime resultTime = futureTime.withHour(23).withMinute(59).withSecond(59);

BlackAccount entity = new BlackAccount();

// 实体字段类型为Date，数据库是timestamp

entity.setDeblockTime(Date.from(resultTime.atZone(ZoneId.systemDefault()).toInstant()));

blackAccountService.save(entity);

❓看到上面的代码，有没有大佬已经发现问题了。确实上面的代码存在问题

解决过程

排查思路

一、排除代码问题

1.确认了项目中所有设置DeblockTime的地方 只有1出。排除了代码逻辑问题，被其他代码覆盖问题；

二、问问AI：

LocalDateTime futureTime = currentTime.plus(oaConfigActivityBlacklist.getBlockDay(), ChronoUnit.DAYS);

LocalDateTime resultTime = futureTime.withHour(23).withMinute(59).withSecond(59);

Date date = Date.from(resultTime.atZone(ZoneId.systemDefault()).toInstant())；

这种写法能保证最后的date 的时分秒为 23时59分59秒么?

ai的答案如下 :

1. 夏令时（DST）影响

• 场景：若时区在目标日期存在夏令时调整（如时钟回拨或前拨），可能导致时间偏差。
• 示例：
  • 假设系统时区为 Europe/Paris，2023 年 10 月 29 日凌晨 3 点时钟回拨到 2 点。
  • 若 futureTime 是该日，设置 23:59:59 后，转换为 UTC 时可能变为 21:59:59Z 或 22:59:59Z，取决于时钟调整规则。

2. 时区转换问题

• 场景：若 currentTime 是其他时区的时间（如 UTC），直接转换可能导致时间偏移。
• 示例：
  • 若 currentTime 是 UTC 时间 2023-10-01T16:00:00Z，系统时区为 Asia/Shanghai（UTC+8）。
  • 添加 1 天后得到 2023-10-02T16:00:00Z，设置为 23:59:59 后转换为 Date，实际对应 UTC 时间 2023-10-02T15:59:59Z。

看了数据的时间分布，任何时间点 都存在 23:59:59 和 00:00:00的情况，就算创建时间相差几分钟的情况下，都存在这两种数据。

三、批量插入数据测试

看看能不能复现这个问题，会不会插入时候精度等其他问题：

for (int i = 0; i < 100; i++) {

    Thread.sleep(100);

   LocalDateTime currentTime = LocalDateTime.now();

   LocalDateTime futureTime = currentTime.plus(2, ChronoUnit.DAYS); 

   // 设置了为当天的最后一秒啊 LocalDateTime resultTime = futureTime.withHour(23).withMinute(59).withSecond(59);

   BlackAccount entity = new BlackAccount(); 

   // 实体字段类型为Date，数据库是timestamp 

   entity.setDeblockTime(Date.from(resultTime.atZone(ZoneId.systemDefault()).toInstant())); 

   blackAccountService.save(entity);

}

果然还真复现了，有一半的数据是2025-06-19 23:59:59 有一半的数据是2025-06-20 00:00:00

定位问题

通过demo的复现，可以确认是在存数据库的时候出了问题。 因为Date的精度是控制在毫秒，pgsql 中TimeStamp 的精度用的默认值，精确到秒，所以在插入的时候Date的毫秒部分大于等于500的时候就会加1秒处理。入库之后就变成了第二天的00:00:00呢

解决方案

要么将java对象的时间精度和 数据库的精度保持一致，要么就将java对象多余的精度置为0，解决方案如下：

• 方案1：代码中清空秒后面的数据
  修改前： futureTime.withHour(23).withMinute(59).withSecond(59);
  修改后： futureTime.withHour(23).withMinute(59).withSecond(59).withNano(0);
• 方案2：调整数据库TimeStamp精度不小于java（date）对象的精度
  修改前： 
  修改后： 

知识扩展

1. Date 和 LocalDateTime

特性	java.util.Date (Java 1.0)	java.time.LocalDateTime (Java 8+)
精度	毫秒级（1/1000 秒）	纳秒级（1/1,000,000,000 秒）
包路径	java.util.Date	java.time.LocalDateTime
可变性	可变（修改会影响原对象）	不可变（所有操作返回新对象）
时区感知	不存储时区，但内部时间戳基于 UTC	无时区，仅表示本地日期和时间

2. mysql 中的timestamp 和 datetime

特性	DATETIME	TIMESTAMP
存储范围	1000-01-01 00:00:00 到 9999-12-31 23:59:59	1970-01-01 00:00:01 UTC 到 2038-01-19 03:14:07 UTC
精度	5.6.4 版本后支持 fractional seconds（如DATETIME(6)）最高精度微妙，设置0的话就表示精确到秒	同上（如TIMESTAMP(6)）
存储空间	8 字节	4 字节（时间戳范围小）
时区感知	不存储时区信息，直接存储字面量	自动转换时区：存储时转换为 UTC，读取时转换为会话时区
默认值	无默认值（除非显式设置DEFAULT）	支持DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP
自动更新	不支持	支持自动更新为当前时间（ON UPDATE）

3.适用场景建议

1. java 中尽量用LocalDateTime吧，毕竟LocalDateTime 主要就是用来取代Date对象的,区别如下

场景类型	java.util.Date（旧 API）	java.time.LocalDateTime（新 API）
简单本地时间记录	可使用，但 API 繁琐（需配合Calendar）	推荐使用（无需时区，代码简洁）
带时区的时间处理	不推荐（时区处理易混淆）	推荐使用ZonedDateTime或OffsetDateTime
多线程环境	不推荐（非线程安全）	推荐（不可变设计，线程安全）
数据库交互（JDBC 4.2+）	需转换为java.sql.Timestamp	直接支持（如pstmt.setObject(1, localDateTime)）
时间计算与格式化	需依赖SimpleDateFormat（非线程安全）	推荐（DateTimeFormatter线程安全）
高精度需求（纳秒级）	仅支持毫秒级	支持纳秒级（1/1,000,000,000 秒

2. 数据库到底是用timestamp 还是 datetime呢,跨国业务用timestamp 其他场景建议用datetime：

场景	推荐类型	原因
存储历史事件时间（如订单创建时间）	DATETIME	不依赖时区，固定记录用户输入的时间
记录服务器本地时间（如定时任务执行时间）	DATETIME	无需时区转换，直接反映服务器时间
多时区应用（如跨国业务）	TIMESTAMP	自动处理时区转换，确保数据一致性（如登录时间）
需要自动更新时间戳	TIMESTAMP	支持ON UPDATE CURRENT_TIMESTAMP特性
存储范围超过 2038 年	DATETIME	TIMESTAMP仅支持到 【2038】 年
微秒级精度需求	DATETIME(6)或TIMESTAMP(6)	根据是否需要时区转换选择

总结

本文主要讲述了在处理用户解封时间时，因 Java 代码中时间精度与数据库TIMESTAMP类型精度不一致，导致约一半数据存储时间比预期多 1 秒的问题。通过排查与测试，定位问题并给出了 Java 对象时间精度和调整数据库精度两种解决方案，同时对比了 Java 和数据库中多种时间类型的特性及适用场景 。

作者：提前退休的java猿
来源：juejin.cn/post/7517119131856191500

1.背景

一开始接到任务需要打印html，之前用到了vue-print-nb-jeecg来处理Vue2一个打印的问题，现在是遇到需求要在Vue3项目里面去打印十几页的打印和下载为pdf，难点和坑就在于我用的库vue3-print-nb来做分页打印预览，下载pdf后面介绍

2.预览打印实现

    <div id="printMe" style="background:red;">

        <p>葫芦娃，葫芦娃</p>

        <p>一根藤上七朵花 </p>

        <p>小小树藤是我家 啦啦啦啦 </p>

        <p>叮当当咚咚当当　浇不大</p>

        <p> 叮当当咚咚当当 是我家</p>

        <p> 啦啦啦啦</p>

        <p>...</p>

    </div>



    <button v-print="'#printMe'">Print local range</button>

因为官方提供的方案都是DOM加载完成后然后直接打印，但是我的需求是需要点击打印的时候根据id渲染不同的组件然后渲染DOM，后面仔细看官方文档，有个beforeOpenCallback方法在打印预览之前有个钩子，但是这个钩子没办法确定我接口加载完毕，所以我的思路就是用户先点击我写的点击按钮事件，等异步渲染完毕之后，我再同步触发真正的打印预览按钮，这样就变相解决了我的需求。

坑

3.掉头发之下载pdf

下载pdf这种需求才是我每次去理发店不敢让tony把我头发打薄的原因，我看了很多技术文章，结合个人业务情况，采取的方案是html2canvas把html转成canvas然后转成图片然后通过jsPDF截取图片分页最后下载到本地。本人秉承着不生产水，只做大自然的搬运工的匠人精神，迅速而又果断的从社区来到社区去，然后找到了适配当前业务的逻辑代码(实践出真知)。

import html2canvas from 'html2canvas'

import jsPDF, { RGBAData } from 'jspdf'



/** a4纸的尺寸[595.28,841.89], 单位毫米 */

const [PAGE_WIDTH, PAGE_HEIGHT] = [595.28, 841.89]



const PAPER_CONFIG = {

  /** 竖向 */

  portrait: {

    height: PAGE_HEIGHT,

    width: PAGE_WIDTH,

    contentWidth: 560

  },

  /** 横向 */

  landscape: {

    height: PAGE_WIDTH,

    width: PAGE_HEIGHT,

    contentWidth: 800

  }

}



// 将元素转化为canvas元素

// 通过 放大 提高清晰度

// width为内容宽度

async function toCanvas(element: HTMLElement, width: number) {

  if (!element) return { width, height: 0 }



  // canvas元素

  const canvas = await html2canvas(element, {

    // allowTaint: true, // 允许渲染跨域图片

    scale: window.devicePixelRatio * 2, // 增加清晰度

    useCORS: true // 允许跨域

  })



  // 获取canvas转化后的宽高

  const { width: canvasWidth, height: canvasHeight } = canvas



  // html页面生成的canvas在pdf中的高度

  const height = (width / canvasWidth) * canvasHeight



  // 转化成图片Data

  const canvasData = canvas.toDataURL('image/jpeg', 1.0)



  return { width, height, data: canvasData }

}



/**

 * 生成pdf(A4多页pdf截断问题， 包括页眉、页脚 和 上下左右留空的护理)

 * @param param0

 * @returns

 */

export async function outputPDF({

  /** pdf内容的dom元素 */

  element,



  /** 页脚dom元素 */

  footer,



  /** 页眉dom元素 */

  header,



  /** pdf文件名 */

  filename,



  /** a4值的方向: portrait or landscape */

  orientation = 'portrait' as 'portrait' | 'landscape'

}) {

  if (!(element instanceof HTMLElement)) {

    return

  }



  if (!['portrait', 'landscape'].includes(orientation)) {

    return Promise.reject(

      new Error(`Invalid Parameters: the parameter {orientation} is assigned wrong value, you can only assign it with {portrait} or {landscape}`)

    )

  }

  const [A4_WIDTH, A4_HEIGHT] = [PAPER_CONFIG[orientation].width, PAPER_CONFIG[orientation].height]



  /** 一页pdf的内容宽度, 左右预设留白 */

  const { contentWidth } = PAPER_CONFIG[orientation]



  // eslint-disable-next-line new-cap

  const pdf = new jsPDF({

    unit: 'pt',

    format: 'a4',

    orientation

  })



  // 一页的高度， 转换宽度为一页元素的宽度

  const { width, height, data } = await toCanvas(element, contentWidth)



  // 添加

  function addImage(

    _x: number,

    _y: number,

    pdfInstance: jsPDF,

    base_data: string | HTMLImageElement | HTMLCanvasElement | Uint8Array | RGBAData,

    _width: number,

    _height: number

  ) {

    pdfInstance.addImage(base_data, 'JPEG', _x, _y, _width, _height)

  }



  // 增加空白遮挡

  function addBlank(x: number, y: number, _width: number, _height: number) {

    pdf.setFillColor(255, 255, 255)

    pdf.rect(x, y, Math.ceil(_width), Math.ceil(_height), 'F')

  }



  // 页脚元素 经过转换后在PDF页面的高度

  const { height: tFooterHeight, data: headerData } = footer ? await toCanvas(footer, contentWidth) : { height: 0, data: undefined }



  // 页眉元素 经过转换后在PDF的高度

  const { height: tHeaderHeight, data: footerData } = header ? await toCanvas(header, contentWidth) : { height: 0, data: undefined }



  // 添加页脚

  async function addHeader(headerElement: HTMLElement) {

    headerData && pdf.addImage(headerData, 'JPEG', 0, 0, contentWidth, tHeaderHeight)

  }



  // 添加页眉

  async function addFooter(pageNum: number, now: number, footerElement: HTMLElement) {

    if (footerData) {

      pdf.addImage(footerData, 'JPEG', 0, A4_HEIGHT - tFooterHeight, contentWidth, tFooterHeight)

    }

  }



  // 距离PDF左边的距离，/ 2 表示居中

  const baseX = (A4_WIDTH - contentWidth) / 2 // 预留空间给左边

  // 距离PDF 页眉和页脚的间距， 留白留空

  const baseY = 15



  // 除去页头、页眉、还有内容与两者之间的间距后 每页内容的实际高度

  const originalPageHeight = A4_HEIGHT - tFooterHeight - tHeaderHeight - 2 * baseY



  // 元素在网页页面的宽度

  const elementWidth = element.offsetWidth



  // PDF内容宽度 和 在HTML中宽度 的比， 用于将 元素在网页的高度 转化为 PDF内容内的高度， 将 元素距离网页顶部的高度  转化为 距离Canvas顶部的高度

  const rate = contentWidth / elementWidth



  // 每一页的分页坐标， PDF高度， 初始值为根元素距离顶部的距离

  const pages = [rate * getElementTop(element)]



  // 获取该元素到页面顶部的高度(注意滑动scroll会影响高度)

  function getElementTop(contentElement) {

    if (contentElement.getBoundingClientRect) {

      const rect = contentElement.getBoundingClientRect() || {}

      const topDistance = rect.top



      return topDistance

    }

  }



  // 遍历正常的元素节点

  function traversingNodes(nodes) {

    for (const element of nodes) {

      const one = element



      /** */

      /** 注意： 可以根据业务需求，判断其他场景的分页，本代码只判断表格的分页场景 */

      /** */



      // table的每一行元素也是深度终点

      const isTableRow = one.classList && one.classList.contains('ant4-table-row')



      // 对需要处理分页的元素，计算是否跨界，若跨界，则直接将顶部位置作为分页位置，进行分页，且子元素不需要再进行判断

      const { offsetHeight } = one

      // 计算出最终高度

      const offsetTop = getElementTop(one)



      // dom转换后距离顶部的高度

      // 转换成canvas高度

      const top = rate * offsetTop

      const rateOffsetHeight = rate * offsetHeight



      // 对于深度终点元素进行处理

      if (isTableRow) {

        // dom高度转换成生成pdf的实际高度

        // 代码不考虑dom定位、边距、边框等因素，需在dom里自行考虑，如将box-sizing设置为border-box

        updateTablePos(rateOffsetHeight, top)

      }

      // 对于普通元素，则判断是否高度超过分页值，并且深入

      else {

        // 执行位置更新操作

        updateNormalElPos(top)

        // 遍历子节点

        traversingNodes(one.childNodes)

      }

      updatePos()

    }

  }



  // 普通元素更新位置的方法

  // 普通元素只需要考虑到是否到达了分页点，即当前距离顶部高度 - 上一个分页点的高度 大于 正常一页的高度，则需要载入分页点

  function updateNormalElPos(top) {

    if (top - (pages.length > 0 ? pages[pages.length - 1] : 0) >= originalPageHeight) {

      pages.push((pages.length > 0 ? pages[pages.length - 1] : 0) + originalPageHeight)

    }

  }



  // 可能跨页元素位置更新的方法

  // 需要考虑分页元素，则需要考虑两种情况

  // 1. 普通达顶情况，如上

  // 2. 当前距离顶部高度加上元素自身高度 大于 整页高度，则需要载入一个分页点

  function updateTablePos(eHeight: number, top: number) {

    // 如果高度已经超过当前页，则证明可以分页了

    if (top - (pages.length > 0 ? pages[pages.length - 1] : 0) >= originalPageHeight) {

      pages.push((pages.length > 0 ? pages[pages.length - 1] : 0) + originalPageHeight)

    }

    // 若 距离当前页顶部的高度 加上元素自身的高度 大于 一页内容的高度, 则证明元素跨页，将当前高度作为分页位置

    else if (

      top + eHeight - (pages.length > 0 ? pages[pages.length - 1] : 0) > originalPageHeight &&

      top !== (pages.length > 0 ? pages[pages.length - 1] : 0)

    ) {

      pages.push(top)

    }

  }



  // 深度遍历节点的方法

  traversingNodes(element.childNodes)



  function updatePos() {

    while (pages[pages.length - 1] + originalPageHeight < height) {

      pages.push(pages[pages.length - 1] + originalPageHeight)

    }

  }



  // 对pages进行一个值的修正，因为pages生成是根据根元素来的，根元素并不是我们实际要打印的元素，而是element，

  // 所以要把它修正，让其值是以真实的打印元素顶部节点为准

  const newPages = pages.map(item => item - pages[0])



  // 根据分页位置 开始分页

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

    // 根据分页位置新增图片

    addImage(baseX, baseY + tHeaderHeight - newPages[i], pdf, data!, width, height)

    // 将 内容 与 页眉之间留空留白的部分进行遮白处理

    addBlank(0, tHeaderHeight, A4_WIDTH, baseY)

    // 将 内容 与 页脚之间留空留白的部分进行遮白处理

    addBlank(0, A4_HEIGHT - baseY - tFooterHeight, A4_WIDTH, baseY)

    // 对于除最后一页外，对 内容 的多余部分进行遮白处理

    if (i < newPages.length - 1) {

      // 获取当前页面需要的内容部分高度

      const imageHeight = newPages[i + 1] - newPages[i]

      // 对多余的内容部分进行遮白

      addBlank(0, baseY + imageHeight + tHeaderHeight, A4_WIDTH, A4_HEIGHT - imageHeight)

    }



    // 添加页眉

    if (header) {

      await addHeader(header)

    }



    // 添加页脚

    if (footer) {

      await addFooter(newPages.length, i + 1, footer)

    }



    // 若不是最后一页，则分页

    if (i !== newPages.length - 1) {

      // 增加分页

      pdf.addPage()

    }

  }

  return pdf.save(filename)

}

4.分页的小姿势

如果有需求把打印预览的时候的页眉页脚默认取消不展示，然后自定义页面的边距可以这么设置样式

@page {

  size: auto A4 landscape;

  margin: 3mm;

}



@media print {

  body,

  html {

    height: initial;

    padding: 0px;

    margin: 0px;

  }

}

5.关于页眉页脚

由于业务是属于比较自定义化的展示，所以我封装成组件，然后根据返回的数据进行渲染到每个界面，然后利用绝对定位放在相同的位置，最后一点小优化就是，公共化提取界面的样式，然后整合为pub.scss然后引入到界面里面，这样即使产品有一定的样式调整，我也可以在公共样式里面去配置和修改，大大的减少本人的工作量。在日常的开发中也是这样，不要去抱怨需求的变动频繁，而是力争在写组件的过程中考虑到组件的健壮性和灵活度，给自己的工作减负，到点下班。

参考文章

juejin.cn/post/732343…

在前端开发中，大屏适配一直是个让人头疼的问题。领导总是要求大屏既要不留白，又要不变形，还要没有滚动条。这看似简单的要求，实际却压根不可能。今天，我们就来聊聊大屏适配的四种常见模式，以及如何根据实际需求选择合适的方案。

一、大屏适配的困境

在大屏项目中，适配问题几乎是每个开发者都会遇到的挑战。屏幕尺寸的多样性、设计稿与实际屏幕的比例差异，都使得适配变得复杂。而领导的“既要...又要...还要...”的要求，更是让开发者们感到无奈。不过，我们可以通过合理选择适配模式来尽量满足这些需求。

二、四种适配模式

在大屏适配中，常见的适配模式有以下四种：

（以下截图中模拟视口1200px*500px和800px*600px，设计稿为1920px*1080px）

1. 拉伸填充（fill）

• 特点：内容会被拉伸变形，以完全填充视口框。这种方式可以确保视口内没有空白区域，但可能会导致内容变形。


• 适用场景：适用于对内容变形不敏感的场景，例如全屏背景图。

2. 保持比例（contain）

• 特点：内容保持原始比例，不会被拉伸变形。如果内容的宽高比与视口不一致，会在视口内出现空白区域（黑边）。这种方式可以确保内容不变形，但可能会留白。


• 适用场景：适用于需要保持内容原始比例的场景，例如视频或图片展示。

3. 滚动显示（scroll）

• 特点：内容不会被拉伸变形，当内容超出视口时会添加滚动条。这种方式可以确保内容完整显示，但用户需要滚动才能查看全部内容。


• 适用场景：适用于内容较多且需要完整显示的场景，例如长列表或长文本。

4. 隐藏超出（hidden）

• 特点：内容不会被拉伸变形，当内容超出视口时会隐藏超出部分。这种方式可以避免滚动条的出现，但可能会隐藏部分内容。


• 适用场景：适用于内容较多但不需要完整显示的场景，例如仪表盘。

三、为什么不能同时满足所有要求？

这四种适配模式各有优缺点，但它们在逻辑上是相互矛盾的。具体来说：

• 不留白：要求内容完全填充视口，没有任何空白区域。这通常需要拉伸或缩放内容以适应视口的宽高比。


• 不变形：要求内容保持其原始宽高比，不被拉伸或压缩。这通常会导致内容无法完全填充视口，从而出现空白区域（黑边）。


• 没滚动条：要求内容完全适应视口，不能超出视口范围。这通常需要隐藏超出部分或限制内容的大小。

这三个要求在逻辑上是相互矛盾的：

• 如果内容完全填充视口（不留白），则可能会变形。


• 如果内容保持原始比例（不变形），则可能会出现空白区域（留白）。


• 如果内容超出视口范围，则需要滚动条或隐藏超出部分。

四、【fitview】插件快速实现大屏适配

fitview 是一个视口自适应的 JavaScript 插件，它支持多种适配模式，能够快速实现大屏自适应效果。

github地址：github.com/pbstar/fitv…

在线预览：pbstar.github.io/fitview

以下是它的基本使用方法：

配置

• el: 需要自适应的 DOM 元素


• fit: 自适应模式，字符串，可选值为 fill、contain（默认值）、scroll、hidden


• resize: 是否监听元素尺寸变化，布尔值，默认值 true

安装引入

npm 安装

npm install fitview

esm 引入

import fitview from "fitview";

cdn 引入

<script src="https://unpkg.com/fitview@[version]/lib/fitview.umd.js"></script>

使用示例

<div id="container">

  <div style="width:1920px;height:1080px;"></div>

</div>

const container = document.getElementById("container");

new fitview({

  el: container,

});

五、总结

大屏适配是一个复杂的问题，不同的项目有不同的需求。虽然不能同时满足“不留白”“不变形”和“没滚动条”这三个要求，但可以通过合理选择适配模式来尽量满足大部分需求。在实际开发中，我们需要根据项目的具体需求和用户体验来权衡，选择最合适的适配方案。

在选择适配方案时，fitview 这个插件可以提供很大的帮助。它支持多种适配模式，能够快速实现大屏自适应效果。如果你正在寻找一个简单易用的适配工具，fitview 值得一试。你可以通过 npm 安装或直接使用 CDN 引入，快速集成到你的项目中。

希望这篇文章能帮助你更好地理解和选择大屏适配方案。如果你有更多问题或建议，欢迎在评论区留言。

作为一名前端开发者，我们一定都遇到过这样的需求：实现一个占满整个屏幕的欢迎页、弹窗蒙层或者一个 fixed 定位的底部菜单。

直觉告诉我们，这很简单，给它一个 height: 100vh 就行了。

.fullscreen-element {

    height: 100vh;

    width: 100%;

    color: #000;

    display: flex;

    justify-content: center;

    align-items: center;

    font-size: 10em;

    background-color: #fff;

}

在PC端预览，完美！然而，当你在手机上打开时，可能会看到下面这个令人抓狂的场景：

明明是 100vh，为什么会超出屏幕高度？这个烦人的滚动条到底从何而来？

如果你也曾为此抓耳挠腮，那么恭喜你，这篇文章就是你的“终极答案”。今天，我将带你彻底搞懂 100vh 在移动端的“坑”，并为你介绍当下最完美的解决方案。

1. 问题根源：移动端动态变化的“视口”

要理解问题的本质，我们首先要明白 vh (Viewport Height) 单位的定义：1vh 等于视口高度的 1%。

在PC端，浏览器窗口大小是相对固定的，所以 100vh 就是浏览器窗口的可见高度，这没有问题。

但在移动端，情况变得复杂了。为了在有限的屏幕空间里提供更好的浏览体验，手机浏览器（尤其是Safari和Chrome）的地址栏和底部工具栏是动态变化的。

• 初始状态：当你刚进入页面时，地址栏和工具栏是完全显示的。


• 滚动时：当你向下滚动页面，这些UI元素会自动收缩，甚至隐藏，以腾出更多空间展示网页内容。

关键点来了：大多数移动端浏览器将 100vh 定义为“最大视口高度”，也就是当地址栏和工具栏完全收起时的高度。

这就导致了：

在页面初始加载、地址栏还未收起时，100vh 的实际计算高度 > 屏幕当前可见区域的高度。

于是，那个恼人的滚动条就出现了。

2. “过去式”的解决方案：JavaScript 动态计算

在很长一段时间里，前端开发者们只能求助于 JavaScript 来解决这个问题。思路很简单：通过 window.innerHeight 获取当前可见视口的高度，然后用它来动态设置元素的 height。

JavaScript

function setRealVH() {

  const vh = window.innerHeight * 0.01;

  document.documentElement.style.setProperty('--vh', `${vh}px`);

}



// 初始加载时设置

window.addEventListener('load', setRealVH);

// 窗口大小改变或旋转屏幕时重新设置

window.addEventListener('resize', setRealVH);

然后在 CSS 中这样使用：

CSS

.fullscreen-element {

  height: calc(var(--vh, 1vh) * 100);

}

这个方案的缺点显而易见：

• 性能开销：监听 resize 事件过于频繁，可能会引发性能问题。


• 逻辑耦合：纯粹的样式问题却需要JS来解决，不够优雅。


• 时机问题：执行时机需要精确控制，否则可能出现闪烁。

虽然能解决问题，但这绝不是我们想要的“终极方案”。

3. “现在时”的终极解决方案：CSS动态视口单位

谢天谢地，CSS 工作组听到了我们的呼声！为了解决这个老大难问题，CSS Values and Units Module Level 4 引入了一套全新的动态视口单位。

它们就是我们今天的“主角”：

• svh (Small Viewport Height): 最小视口高度。对应于地址栏和工具栏完全展开时的可见高度。


• lvh (Large Viewport Height): 最大视口高度。对应于地址栏和工具栏完全收起时的高度（这其实就等同于旧的 100vh）。


• dvh (Dynamic Viewport Height): 动态视口高度。这是最智能、最实用的单位！它的值会随着浏览器UI元素（地址栏）的出现和消失而动态改变。

所以，我们的终极解决方案就是：

CSS

.fullscreen-element {

  height: 100svh; /* 如果你希望高度固定，且永远不被遮挡 */

  /* 或者，也是我最推荐的 */

  height: 100dvh; /* 如果你希望元素能动态地撑满整个可见区域 */

}

使用 100dvh，当地址栏收起时，元素高度会平滑地增加以填满屏幕；当地址栏滑出时，元素高度又会平滑地减小。整个过程如丝般顺滑，没有任何滚动条，完美！

浏览器兼容性

你可能会担心兼容性问题。好消息是，从2023年开始，所有主流现代浏览器（Safari, Chrome, Edge, Firefox）都已经支持了这些新的视口单位。

(数据截至2025年6月，兼容性已非常好)

可以看到，兼容性已经非常理想。除非你需要支持非常古老的浏览器版本，否则完全可以放心地在生产环境中使用。

告别 100vh 的时代

让我们来快速回顾一下：

当需要实现移动端全屏布局时，请大胆地告别 100vh，拥抱 100dvh！

原文：Alexander Belanger - 2025.06.03

如同地球上几乎所有人一样，过去的几个月里，我们也一直在关注着 Agent 的发展。

特别值得一提的是，我们观察到 Agent 的采用推动了我们编排平台的增长，这让我们对哪些技术栈和框架——或者干脆没有框架——在此领域表现良好有了一些见解。

我们看到的一个更有趣的现象是混合技术栈的激增：一个典型的 Next.js 或 FastAPI 后端，搭配着一个用 Go 语言编写的 Agent，甚至在非常早期阶段就如此。

作为一名长期的 Go 语言开发者，这着实令人兴奋；下面我将解释为何我认为这将成为未来更普遍的做法。

什么是 Agent？

这里的术语有些混乱，但通常我指的是一个在循环中执行的进程，该进程对其执行路径中的下一步操作拥有一定的自主权。这与预定义的执行路径（例如定义为有向无环图的一组步骤，我们称之为工作流）形成对比。Agent 通常包含一个基于最大深度或满足某个条件（如“测试通过”）的退出条件。

当 Agent 开始规模化（即：拥有实际用户）时，它们通常具有一些共同特征：

让我们将这一系列特征转化为对运行时的要求。为了限定问题范围，假设我们正在处理一个在远程执行的 Agent，而非在用户本地机器上（尽管 Go 对于分发本地 Agent 也是一个绝佳选择）。在远程执行的情况下，为每次 Agent 执行运行一个单独的容器成本会高得惊人。因此，在大多数情况下（尤其是当我们的 Agent 主要是简单的 I/O 和 LLM 调用时），我们最终会得到大量并发运行的轻量级进程。每个进程可以处于特定状态（例如，“搜索文件中”、“生成代码中”、“测试中”）。请注意，不同 Agent 执行的状态顺序可能并不相同。

这种包含许多并发、长时间运行进程的系统，与大约十年前的传统 Web 架构截然不同。在传统架构中，对服务器的请求处理速度要快得多，使用一些缓存、高效的处理程序和 OLTP 数据库就能高效地服务数千名日活用户。

事实证明，这种架构转变非常适合 Go 语言的并发模型、依赖通道（channel）进行通信、集中的取消机制以及围绕 I/O 构建的工具链。

高并发性

让我们从最明显的一点开始——Go 拥有极其简单且强大的并发模型。创建一个新的 goroutine 所需的内存和时间成本非常低，因为每个 goroutine 只有 2KB 的预分配内存。

这实际上意味着你可以同时运行许多 goroutine 而开销很小，并且它们在底层运行在多个操作系统线程上，能够利用服务器中的所有 CPU 核心。这一点非常重要，因为如果你碰巧在某个 goroutine 中执行非常消耗 CPU 的操作（比如反序列化一个大型 JSON 结构），其影响会比你使用单线程运行时（如 Node.js）要小（在 Node.js 中，你需要为阻塞线程的操作创建 worker 线程或子进程），或者比使用 Python 的 async/await 也要好。

这对于 Agent 意味着什么？因为 Agent 的运行时间比典型的 Web 请求长得多，所以并发性就成为了一个更关键的问题。在 Go 中，相比于在 Python 中为每个 Agent 运行一个线程，或者在 Node.js 中为每个 Agent 运行一个 async 函数，你受到为每个 Agent 生成一个 goroutine 的限制要小得多。再加上较低的基础内存占用和编译成单一二进制文件的特点，在轻量级基础设施上同时运行数千个并发 Agent 执行变得异常简单。

通过通信共享内存

对于那些不了解的人，Go 语言有一个常见的习语：不要通过共享内存来通信；相反，通过通信来共享内存。

在实践中，这意味着不需要尝试跨多个并发进程同步内存内容（这是使用类似 Python 的 multithreading 库时的常见问题），每个进程可以通过在通道（channel）上获取和释放对象来获得该对象的所有权。这样做的效果是，每个进程只在拥有对象所有权时关心该对象的本地状态，而其他时候不需要协调所有权——无需互斥锁（mutex）！

老实说——在我编写过的大多数 Go 程序中，我使用等待组（wait groups）和互斥锁（mutexes）的次数往往比使用通道（channels）更多，因为这样通常更简单（这也符合 Go 社区的建议），并且只有一个地方需要并发访问数据。

但是，在建模 Agent 时，这种范式非常有用，因为 Agent 通常需要异步响应用户或其他 Agent 发来的消息，并且将应用程序实例视为一个 Agent 池来思考是很有帮助的。

为了更具体说明，让我们编写一些示例代码来表示 Agent 循环的核心逻辑：

// 注意：在真实世界的例子中，我们需要一种机制来优雅地

// 关闭循环并防止通道关闭；

// 这是一个简化示例。

func Agent(in <-chan Message, out chan<- Output, status chan<- State) {

    internal := make(chan Message, 10) // 内部缓冲区大小为 10 的通道



    for {

        select {

        case msg := <-internal: // 从内部通道读取消息

            processMessage(msg, internal, out, status)

        case msg := <-in: // 从外部输入通道读取消息

            processMessage(msg, internal, out, status)

        }

    }

}



func processMessage(msg Message, internal chan<- Message, out chan<- Output, status chan<- State) {

    result := execute(msg) // 执行消息处理

    status <- State{msg.sessionId, result.status} // 发送状态更新



    if next := result.next(); next != nil { // 获取下一步消息（如果有）

        internal <- next // 将下一步消息发送到内部通道

    }



    out <- result // 发送处理结果

}

(请注意，<-chan 表示接收者只能从通道读取，而 chan<- 表示接收者只能向通道写入。)

这个 Agent 是一个长时间运行的进程，它等待消息到达 in 通道，处理消息，然后异步地将结果发送到 out 通道。status 通道用于发送关于 Agent 状态的更新，这对于监控或向用户发送增量结果很有用；而 internal 通道用于处理 Agent 的内部循环。例如，内部循环可以实现下图中的“直到测试通过”循环：

尽管我们使用 for 循环来运行 Agent，但该 Agent 的实例在消息之间不需要维护任何内部状态。它本质上是一个无状态归约器，其决策执行路径的下一步操作不依赖于某些内部状态。重要的是，这意味着任何 Agent 实例都能够处理下一条消息。这也允许 Agent 在消息之间使用持久化边界，例如将消息写入数据库或消息队列。

使用 context.Context 的集中取消机制

还记得 Agent 执行成本很高吗？假设一个用户触发了一个价值 10 美元的执行任务，但突然改变主意并点击“停止生成”——为了节省成本，你希望取消这次执行。

事实证明，在 Node.js 和 Python 中取消长时间运行的工作极其困难，原因有很多：

幸运的是，Go 采用 context.Context 使得取消工作变得轻而易举，因为绝大多数库都预期并尊重这种模式。即使某些库不支持：由于 Go 只有一种并发模型，因此有像 goleak 这样的工具，可以更容易地检测出泄漏的 goroutine 和有问题的库。

丰富的标准库

当你开始使用 Go 时，你会立即注意到 Go 的标准库非常丰富且质量很高。它的许多部分也是为 Web I/O 构建的——比如 net/http、encoding/json 和 crypto/tls——这些对于 Agent 的核心逻辑非常有用。

Go 还有一个隐含的假设：所有 I/O 在 goroutine 内部都是阻塞的——再次强调，因为 Go 只有一种方式运行并发工作——这鼓励你将业务逻辑的核心编写为直线式程序。你不需要担心用 await 包装每个函数调用来将执行推迟给调度器。

与 Python 对比：库开发者需要考虑 asyncio、多线程（multithreading）、多进程（multiprocessing）、eventlet、gevent 以及其他一些模式，几乎不可能同等地支持所有并发模型。因此，如果你用 Python 编写 Agent，你需要研究每个库对你所采用的并发模型的支持情况，并且如果你的第三方库不完全支持你想要的模式，你可能需要采用多种模式。

（Node.js 的情况要好得多，尽管 Bun 和 Deno 等其他运行时的加入增加了一些不兼容的层面。）

性能剖析（Profiling）

由于其有状态性（statefulness）和大量长时间运行的进程，Agent 似乎特别容易出现内存泄漏和线程泄漏。Go 在 runtime/pprof 中提供了出色的工具，可以使用堆（heap）和分配（alloc）配置文件找出内存泄漏的来源，或者使用 goroutine 配置文件找出 goroutine 泄漏的来源。

额外优势：LLM 擅长编写 Go 代码

由于 Go 语法非常简单（一个常见的批评是 Go 有点“啰嗦”）并且拥有丰富的标准库，LLM 非常擅长编写符合 Go 语言习惯的代码。我发现它们在编写表格测试（table tests）方面尤其出色，这是 Go 代码库中的一种常见模式。

Go 工程师也往往反对框架（anti-framework），这意味着 LLM 不需要跟踪你使用的是哪个框架（或框架的哪个版本）。

不足之处

尽管有以上诸多好处，仍然有很多理由让你可能不会选择 Go 来开发你的 Agent：

随着人工智能技术的不断发展，图像处理应用已经在医疗影像分析、自动驾驶、视频监控等领域得到广泛应用。TensorFlow.js 是 Google 开源的机器学习库 TensorFlow 的 JavaScript 版本，能够让开发者在浏览器中运行机器学习模型，在前端应用中轻松实现图像分类、物体检测和姿态估计等功能。本文将介绍如何使用 TensorFlow.js 在纯前端环境中实现这三项任务，并帮助你构建一个智能图像处理应用。

什么是 TensorFlow.js？

TensorFlow.js 是一个能够让开发者在前端直接运行机器学习模型的 JavaScript 库。它允许你无需将数据发送到服务器，便可以在浏览器中运行模型进行推理，这不仅减少了延迟，还可以更好地保护用户的隐私数据。通过 TensorFlow.js，前端开发者能够轻松实现图像分类、物体检测和姿态估计等功能。

TensorFlow.js 的应用非常广泛，尤其是在一些实时交互和隐私敏感的场景下，例如 医疗影像分析、自动驾驶 和 智能监控。在这些领域，前端模型推理能够提升响应速度，并且避免将用户的数据上传到服务器，从而保护用户的隐私。

要开始使用 TensorFlow.js，你需要安装相关的模型库。以下是你需要安装的 npm 包：

npm install @tensorflow/tfjs

npm install @tensorflow-models/mobilenet

npm install @tensorflow-models/coco-ssd

npm install @tensorflow-models/posenet

加载预训练模型

在 TensorFlow.js 中，加载预训练模型非常简单。首先，确保 TensorFlow.js 已经准备好，然后加载所需的模型进行推理。

// 导入

import * as tf from '@tensorflow/tfjs'

// 加载

tf.ready(); // 确保 TensorFlow.js 准备好

用户上传图片

为了使用这些模型进行推理，我们需要让用户上传一张图片。以下是一个处理图片上传的代码示例：

const handleImageUpload = async (event) => {

  const file = event.target.files[0]

  if (file) {

    const reader = new FileReader()

    reader.onload = async (e) => {

      imageSrc.value = e.target.result

      await runModels(e.target.result)

    }

    reader.readAsDataURL(file)

  }

}

图像分类：识别图片中的物体

图像分类是计算机视觉中的基本任务，目的是将输入图像归类到某个类别中。例如，我们可以用图像分类模型识别图像中的“猫”还是“狗”。

使用预训练模型进行图像分类

TensorFlow.js 提供了多个预训练模型，MobileNet 是其中一个常用的图像分类模型。它是一个轻量级的卷积神经网络，适合用来进行图像分类。接下来，我们通过 MobileNet 实现一个图像分类功能：

const mobilenetModel = await mobilenet.load()

const predictions = await mobilenetModel.classify(image)

classification.value = `分类结果: ${predictions[0].className}, 信心度: ${predictions[0].probability.toFixed(3)}`

这段代码实现了图像分类。我们加载 MobileNet 模型，并对用户上传的图像进行推理，最后返回图像的分类结果。

物体检测：找出图像中的所有物体

物体检测不仅仅是识别图像中的物体是什么，还需要标出它们的位置，通常用矩形框来框住物体。Coco-SSD 是一个强大的物体检测模型，能够在图像中检测出多个物体并标出它们的位置。

使用 Coco-SSD 进行物体检测

const cocoModel = await cocoSsd.load();

const detectionResults = await cocoModel.detect(image);

objects.value = detectionResults.map((prediction) => ({

  class: prediction.class,

  bbox: prediction.bbox,

}));

通过 Coco-SSD 模型，我们可以检测图像中的多个物体，并标出它们的位置。

绘制物体的边界框

为了更直观地展示检测结果，我们可以在图像上绘制出物体的边界框：

// 绘制物体检测边界框

const drawObjects = (detectionResults, image) => {

  nextTick(() => {

    const ctx = objectCanvas.value.getContext('2d')

    const imageWidth = image.width

    const imageHeight = image.height

    objectCanvas.value.width = imageWidth

      objectCanvas.value.height = imageHeight

      ctx.clearRect(0, 0, objectCanvas.value.width, objectCanvas.value.height)

      ctx.drawImage(image, 0, 0, objectCanvas.value.width, objectCanvas.value.height)

      // 绘制边界框

      detectionResults.forEach((prediction) => {

        const [x, y, width, height] = prediction.bbox

        ctx.beginPath()

        ctx.rect(x, y, width, height)

        ctx.lineWidth = 2

        ctx.strokeStyle = 'green'

        ctx.stroke()

        // 添加标签

        ctx.font = '16px Arial'

        ctx.fillStyle = 'green'

        ctx.fillText(prediction.class, x + 5, y + 20)

      })

  })

}