WebSocket 和 Socket 的区别

WebSocket 和 Socket 是两种不同的网络通信技术，它们在使用场景、协议、功能等方面有显著的差异。以下是它们之间的主要区别：

1. 定义

• Socket：Socket 是一种网络通信的工具，可以实现不同计算机之间的数据交换。它是操作系统提供的 API，广泛应用于 TCP/IP 网络编程中。Socket 可以是流式（TCP）或数据报（UDP）类型的，用于低层次的网络通信。


• WebSocket：WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议。它允许服务器和客户端之间实时地交换数据。WebSocket 是建立在 HTTP 协议之上的，主要用于 Web 应用程序，以实现实时数据传输。

2. 协议层次

• Socket：Socket 是一种底层通信机制，通常与 TCP/IP 协议一起使用。它允许开发者通过编程语言直接访问网络接口。


• WebSocket：WebSocket 是一种应用层协议，建立在 HTTP 之上。在初始握手时，使用 HTTP 协议进行连接，之后切换到 WebSocket 协议进行数据传输。

3. 连接方式

• Socket：Socket 通常需要手动管理连接的建立和关闭。通过调用相关的 API，开发者需要处理连接的状态，确保数据的可靠传输。


• WebSocket：WebSocket 的连接管理相对简单。建立连接后，不需要频繁地进行握手，可以保持持久连接，随时进行数据交换。

4. 数据传输模式

• Socket：Socket 可以实现单向或双向的数据传输，但通常需要在发送和接收之间进行明确的控制。


• WebSocket：WebSocket 支持全双工通信，客户端和服务器之间可以随时互相发送数据，无需等待响应。这使得实时通信变得更加高效。

5. 适用场景

• Socket：Socket 常用于需要高性能、低延迟的场景，如游戏开发、文件传输、P2P 网络等。由于其底层特性，Socket 适合对网络性能有严格要求的应用。


• WebSocket：WebSocket 主要用于 Web 应用程序，如即时聊天、实时通知、在线游戏等。由于其易用性和高效性，WebSocket 特别适合需要实时更新和交互的前端应用。

6. 数据格式

• Socket：Socket 发送的数据通常是二进制流或文本流，需要开发者自行定义数据格式和解析方式。


• WebSocket：WebSocket 支持多种数据格式，包括文本（如 JSON）和二进制（如 Blob、ArrayBuffer）。WebSocket 的数据传输格式非常灵活，易于与 JavaScript 进行交互。

7. 性能

• Socket：Socket 对于大量并发连接的处理性能较高，但需要开发者进行优化和管理。


• WebSocket：WebSocket 在建立连接后可以保持长连接，减少了握手带来的延迟，适合高频率的数据交换场景。

8. 安全性

• Socket：Socket 的安全性取决于使用的协议（如 TCP、UDP）和应用层的实现。开发者需要自行处理安全问题，如加密和身份验证。


• WebSocket：WebSocket 支持通过 WSS（WebSocket Secure）进行加密，提供更高层次的安全保障。它可以很好地与 HTTPS 集成，确保数据在传输过程中的安全性。

9. 浏览器支持

• Socket：Socket 是底层的网络通信技术，通常不直接在浏览器中使用。Web 开发者需要通过后端语言（如 Node.js、Java、Python）来实现 Socket 通信。


• WebSocket：WebSocket 是专为 Web 应用设计的，所有现代浏览器均支持 WebSocket 协议，开发者可以直接在客户端使用 JavaScript API 进行通信。

10. 工具和库

• Socket：使用 Socket 进行开发时，开发者通常需要使用底层网络编程库，如 BSD Sockets、Java Sockets、Python's socket 模块等。


• WebSocket：WebSocket 提供了简单的 API，开发者可以使用原生 JavaScript 或第三方库（如 Socket.IO）轻松实现 WebSocket 通信。

结论

总结来说，WebSocket 是一种为现代 Web 应用量身定制的协议，具有实时、双向通信的优势，而 Socket 是一种底层的网络通信机制，提供更灵活的使用方式。选择使用哪种技术取决于具体的应用场景和需求。对于需要实时交互的 Web 应用，WebSocket 是更合适的选择；而对于底层或高性能要求的网络通信，Socket 提供了更多的控制和灵活性。

AI应用已经渗透到我们生活的方方面面。其中，AI对话系统因其自然、流畅的交流方式而备受瞩目。前段时间有人在交流群中问到，如何实现AI对话中那种逐字输出的效果，这背后，流式返回技术发挥了关键作用。

欢迎加入前端筱园交流群：点击加入交流群

​ 其实这背后并不是前端做了什么特效，而是采用的流式返回，而不是一次性返回完整的响应。流式返回允许服务器在一次连接中逐步发送数据，而不是一次性返回全部结果。这种方式使得前端可以在等待完整响应的过程中，逐步展示生成的内容，从而极大地提升了用户体验。

​ 那么，前端接收流式返回具体有哪些方式呢？接下来，本文将详细探讨几种常见的技术手段，帮助读者更好地理解并应用流式返回技术。

使用 Axios

大多数场景下，前端用的最多的就是axios来发送请求，但是axios 只有在在Node.js环境中支持设置 responseType: 'stream' 来接收流式响应。

const axios = require('axios');

const fs = require('fs');



axios.get('http://localhost:3000/stream', {

    responseType: 'stream', // 设置响应类型为流

})

    .then((response) => {

        // 将响应流写入文件

        response.data.pipe(fs.createWriteStream('output.txt'));

    })

    .catch((error) => {

        console.error('Stream error:', error);

    });

特点

• 仅限 Node.js：浏览器中的 axios 不支持 responseType: 'stream'。


• 适合文件下载：适合处理大文件下载。

使用 WebSocket

WebSocket 是一种全双工通信协议，适合需要双向实时通信的场景。

前端代码：

const socket = new WebSocket('ws://localhost:3000');



socket.onopen = () => {

    console.log('WebSocket connected');

};

socket.onmessage = (event) => {

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

};

socket.onerror = (error) => {

    console.error('WebSocket error:', error);

};

socket.onclose = () => {

    console.log('WebSocket closed');

};

服务器代码

const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 3000 });



wss.on('connection', (ws) => {

    console.log('Client connected');



    let counter = 0;

    const intervalId = setInterval(() => {

        counter++;

        ws.send(JSON.stringify({ message: 'Hello', counter }));



        if (counter >= 5) {

            clearInterval(intervalId);

            ws.close();

        }

    }, 1000);



    ws.on('close', () => {

        console.log('Client disconnected');

        clearInterval(intervalId);

    });

});

虽然WebSocket作为一种在单个TCP连接上进行全双工通信的协议，具有实时双向数据传输的能力，但AI对话情况下可能并不选择它进行通信。主要有以下几点原因：

• 在AI对话场景中，通常是用户向AI模型发送消息，模型回复消息的单向通信模式，WebSocket的双向通信能力在此场景下并未被充分利用


• 使用WebSocket可能会引入不必要的复杂性，如处理双向数据流、管理连接状态等，也会增加额外的部署与维护工作

特点

• 双向通信：适合实时双向数据传输


• 低延迟：基于 TCP 协议，延迟低


• 复杂场景：适合聊天、实时游戏等复杂场景

使用 XMLHttpRequest

虽然 XMLHttpRequest 不能直接支持流式返回，但可以通过监听 progress 事件模拟逐块接收数据

const xhr = new XMLHttpRequest();

xhr.open('GET', '/stream', true);



xhr.onprogress = (event) => {

    const chunk = xhr.responseText; // 获取当前接收到的数据

    console.log(chunk);

};



xhr.onload = () => {

    console.log('Request complete');

};



xhr.send();

服务器代码（Koa 示例）：

router.get("/XMLHttpRequest", async (ctx, next) => {

    ctx.set({

        "Content-Type": "text/event-stream",

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

        Connection: "keep-alive",

    });

    // 创建一个 PassThrough 流

    const stream = new PassThrough();

    ctx.body = stream;

    let counter = 0;

    const intervalId = setInterval(() => {

        counter++;

        ctx.res.write(

            JSON.stringify({ message: "Hello", counter })

        );



        if (counter >= 5) {

            clearInterval(intervalId);

            ctx.res.end();

        }

    }, 1000);



    ctx.req.on("close", () => {

        clearInterval(intervalId);

        ctx.res.end();

    });

});

可以看到以下的输出结果，在onprogress中每次可以拿到当前已经接收到的数据。它并不支持真正的流式响应，用于AI对话场景中，每次都需要将以显示的内容全部替换，或者需要做一些额外的处理。

如果想提前终止请求，可以使用 xhr.abort() 方法；

setTimeout(() => {

    xhr.abort();

}, 3000);

特点

• 兼容性好：支持所有浏览器。


• 非真正流式：XMLHttpRequest 仍然需要等待整个响应完成，progress 事件只是提供了部分数据的访问能力。


• 内存占用高：不适合处理大文件。

使用 Server-Sent Events (SSE)

SSE 是一种服务器向客户端推送事件的协议，基于 HTTP 长连接。它适合服务器向客户端单向推送实时数据

前端代码：

const eventSource = new EventSource('/sse');



eventSource.onmessage = (event) => {

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

};



eventSource.onerror = (event) => {

    console.error('EventSource failed:', event);

};

服务器代码（Koa 示例）：

router.get('/sse', (ctx) => {

    ctx.set({

        'Content-Type': 'text/event-stream',

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

        'Connection': 'keep-alive',

    });



    let counter = 0;

    const intervalId = setInterval(() => {

        counter++;

        ctx.res.write(`data: ${JSON.stringify({ message: 'Hello', counter })}\n\n`);



        if (counter >= 5) {

            clearInterval(intervalId);

            ctx.res.end();

        }

    }, 1000);



    ctx.req.on('close', () => {

        clearInterval(intervalId);

        ctx.res.end();

    });

});

EventSource 也具有主动关闭请求的能力，在结果没有完全返回前，用户可以提前终止内容的返回。

// 在需要时中止请求

setTimeout(() => {

    eventSource.close(); // 主动关闭请求

}, 3000); // 3 秒后中止请求

虽然EventSource支持流式请求，但AI对话场景不使用它有以下几点原因：

• 单向通信


• 仅支持 get 请求：在 AI 对话场景中，通常需要发送用户输入（如文本、文件等），这需要使用 POST 请求


• 无法自定义请求头：EventSource 不支持自定义请求头（如 Authorization、Content-Type 等），在 AI 对话场景中，通常需要设置认证信息（如 API 密钥）或指定请求内容类型

注意点

返回给 EventSource 的值必须遵循 data: 开头并以 \n\n 结尾的格式，这是因为 Server-Sent Events (SSE) 协议规定了这种格式。SSE 是一种基于 HTTP 的轻量级协议，用于服务器向客户端推送事件。为了确保客户端能够正确解析服务器发送的数据，SSE 协议定义了一套严格的格式规范。SSE 协议规定，服务器发送的每条消息必须遵循以下格式：

field: value\n

其中 field 是字段名，value 是对应的值。常见的字段包括：

• data:：消息的内容（必须）。


• event:：事件类型（可选）。


• id:：消息的唯一标识符（可选）。


• retry:：客户端重连的时间间隔（可选）。

每条消息必须以 两个换行符 (\n\n) 结尾，表示消息结束

以下是一个完整的 SSE 消息示例：

id: 1\n

event: update\n

data: {"message": "Hello", "counter": 1}\n\n

特点

• 单向通信：适合服务器向客户端推送数据。


• 简单易用：基于 HTTP 协议，无需额外协议支持。


• 自动重连：EventSource 会自动处理连接断开和重连

使用 fetch API

fetch API 是现代浏览器提供的原生方法，支持流式响应。通过 response.body，可以获取一个 ReadableStream，然后逐块读取数据。

前端代码：

// 发送流式请求

fetch("http://localhost:3000/stream/fetch", {

    method: "POST",

    signal,

})

    .then(async (response: any) => {

        const reader = response.body.getReader();

        while (true) {

            const { done, value } = await reader.read();

            if (done) break;

            console.log(new TextDecoder().decode(value));

        }

    })

    .catch((error) => {

        console.error("Fetch error:", error);

    });

服务器代码（Koa 示例）：

router.post("/fetch", async (ctx) => {

    ctx.set({

        "Content-Type": "text/event-stream",

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

        Connection: "keep-alive",

    });

    // 创建一个 PassThrough 流

    const stream = new PassThrough();

    ctx.body = stream;

    let counter = 0;

    const intervalId = setInterval(() => {

        counter++;

        ctx.res.write(JSON.stringify({ message: "Hello", counter }));



        if (counter >= 5) {

            clearInterval(intervalId);

            ctx.res.end();

        }

    }, 1000);



    ctx.req.on("close", () => {

        clearInterval(intervalId);

        ctx.res.end();

    });

});

fetch也同样可以在客户端主动关闭请求。

// 创建一个 AbortController 实例

const controller = new AbortController();

const { signal } = controller;

// 发送流式请求

fetch("http://localhost:3000/stream/fetch", {

    method: "POST",

    signal,

})

    .then(async (response: any) => {

        const reader = response.body.getReader();

        while (true) {

            const { done, value } = await reader.read();

            if (done) break;

            console.log(new TextDecoder().decode(value));

        }

    })

    .catch((error) => {

        console.error("Fetch error:", error);

    });



// 在需要时中止请求

setTimeout(() => {

    controller.abort(); // 主动关闭请求

}, 3000); // 3 秒后中止请求

打开控制台，可以看到在Response中可以看到返回的全部数据，在EventStream中没有任何内容。

这是由于返回的信息SSE协议规范，具体规范见上文的 Server-Sent Events 模块中有介绍到

ctx.res.write(

    `data: ${JSON.stringify({ message: "Hello", counter })}\n\n`

);

但是客户端fetch请求中接收到的数据也包含了规范中的内容，需要前端对数据进一步的处理一下

特点

• 原生支持：现代浏览器均支持 fetch 和 ReadableStream。


• 逐块处理：可以实时处理每个数据块，而不需要等待整个响应完成。


• 内存效率高：适合处理大文件或实时数据。

总结

综上所述，在 AI 对话场景中，fetch 请求 是主流的技术选择，而不是 XMLHttpRequest 或 EventSource。以下是原因和详细分析：

• fetch 是现代浏览器提供的原生 API，基于 Promise，代码更简洁、易读


• fetch 支持 ReadableStream，可以实现流式请求和响应


• fetch 支持自定义请求头、请求方法（GET、POST 等）和请求体


• fetch 结合 AbortController 可以方便地中止请求


• fetch 的响应对象提供了 response.ok 和 response.status，可以更方便地处理错误

最后来看一个接入deekseek的完整例子：

resource.dengzhanyong.com/mp4/7823928…

服务器代码（Koa 示例）：

const openai = new OpenAI({

    baseURL: "https://api.deepseek.com",

    apiKey: "这里是你申请的deepseek的apiKey",

});





// 流式请求 DeepSeek 接口并流式返回

router.post("/fetchStream", async (ctx) => {

    // 设置响应头

    ctx.set({

        "Content-Type": "text/event-stream",

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

        Connection: "keep-alive",

    });



    try {

        // 创建一个 PassThrough 流

        const stream = new PassThrough();

        ctx.body = stream;



        // 调用 OpenAI API，启用流式输出

        const completion = await openai.chat.completions.create({

            model: "deepseek-chat", // 或 'gpt-3.5-turbo'

            messages: [{ role: "user", content: "请用 100 字介绍 OpenAI" }],

            stream: true, // 启用流式输出

        });

        // 逐块处理流式数据

        for await (const chunk of completion) {

            const content = chunk.choices[0]?.delta?.content || ""; // 获取当前块的内容

            ctx.res.write(content);

            process.stdout.write(content); // 将内容输出到控制台

        }

        ctx.res.end();

    } catch (err) {

        console.error("Request failed:", err);

        ctx.status = 500;

        ctx.res.write({ error: "Failed to stream data" });

    }

});

前端代码：

const controller = new AbortController();

const { signal } = controller;

const Chat = () => {

    const [text, setText] = useState<string>("");

    const [message, setMessage] = useState<string>("");

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



    function send() {

        if (!message) return;

        setText(""); // 创建一个 AbortController 实例

        setLoading(true);



        // 发送流式请求

        fetch("http://localhost:3000/deepseek/fetchStream", {

            method: "POST",

            headers: {

                "Content-Type": "application/json",

            },

            body: JSON.stringify({

                message,

            }),

            signal,

        })

            .then(async (response: any) => {

                const reader = response.body.getReader();

                while (true) {

                    const { done, value } = await reader.read();

                    if (done) break;

                    const data = new TextDecoder().decode(value);

                    console.log(data);

                    setText((t) => t + data);

                }

            })

            .catch((error) => {

                console.error("Fetch error:", error);

            })

            .finally(() => {

                setLoading(false);

            });

    }



    function stop() {

        controller.abort();

        setLoading(false);

    }



    return (

        <div>

            <Input

                value={message}

                onChange={(e) => setMessage(e.target.value)}

            />

            <Button

                onClick={send}

                type="primary"

                loading={loading}

                disabled={loading}

            >

                发送

            </Button>

            <Button onClick={stop} danger>

                停止回答

            </Button>

            <div>{text}</div>

        </div>

    );

};

写在最后

欢迎加入前端筱园交流群：点击加入交流群

关注我的公众号【前端筱园】，不错过每一篇推送

electron+node-serialport串口通信

公司项目需求给客户开发一个能与电子秤硬件通信的Win7客户端，提供数据读取、处理和显示功能。项目为了兼容win7使用了electron 22.0.0版本,串口通信使用了serialport 12.0.0版本

serialport文档 electron文档

 //serialport的基本使用方法

 //安装 npm i serialport

 import { SerialPort } from 'serialport'

 SerialPort.list()//获取串口列表

 /** 创建一个串口连接

     path（必需）：串口设备的路径。例如，'/dev/robot' 或 'COM1'。

     baudRate（必需）：波特率，即每秒传输的比特数。常见值有 9600、19200、38400、57600、115200 等。

     autoOpen（可选）：是否在创建对象时自动打开串口。默认为 true。如果设置为 false，你需要手动调用 port.open() 来打开串口。

     dataBits（可选）：每字节的数据位数。可以是 5、6、7、8。默认值是 8。

     stopBits（可选）：停止位的位数。可以是 1 或 2。默认值是 1。

     parity（可选）：校验位类型。可以是 'none'、'even'、'odd'、'mark'、'space'。默认值是 'none'。

     rtscts（可选）：是否启用硬件流控制（RTS/CTS）。布尔值，默认值是 false。

     xon（可选）：是否启用软件流控制（XON）。布尔值，默认值是 false。

     xoff（可选）：是否启用软件流控制（XOFF）。布尔值，默认值是 false。

     xany（可选）：是否启用软件流控制（XANY）。布尔值，默认值是 false。

     highWaterMark（可选）：用于流控制的高水位标记。默认值是 16384（16KB）。

     lock（可选）：是否锁定设备文件，防止其他进程访问。布尔值，默认值是 true。

 **/

 const serialport = new SerialPort({ path: '/dev/example', baudRate: 9600 })

 

 serialport.open()//打开串口

 serialport.write('ROBOT POWER ON')//向串口发送数据

 serialport.on('data', (data) => {//接收数据

    //data为串口接收到的数据

 })

获取串口列表

 //主进程main.ts

 import { SerialPort, SerialPortOpenOptions } from 'serialport'

 //初始化先获取串口列表,提供给页面选择

 ipcMain.on('initData', async () => {

   const portList = await SerialPort.list()

   mainWindow.webContents.send('initData', {portList})

 })

 //渲染进程

 window.electron.ipcRenderer.once('initData', (_,{portList}) => {

   //获取串口列表后存入本地,登录页直接做弹窗给客户选择串口,配置波特率

   window.localStorage.setItem('portList', JSON.stringify(portList))

 })

串口选择

波特率配置

读取数据

公司秤和客户的秤串口配置不一样,所以做了model1和model2区分

 //主进程main.ts

 let P: SerialPort | undefined

 ipcMain.on('beginSerialPort', (_, { path, baudRate }) => {

   //区分配置

   const portConfig: SerialPortOpenOptions<AutoDetectTypes> =

     import.meta.env.VITE_MODE == 'model1'

       ? {

           path: path || 'COM1',

           baudRate: +baudRate || 9600, //波特率

           autoOpen: true,

           dataBits: 8

         }

       : {

           path: path || 'COM1',

           baudRate: +baudRate || 115200, //波特率

           autoOpen: true,

           dataBits: 8,

           stopBits: 1,

           parity: undefined

         }

   if (P) {

     P.close((error) => {

       if (error) {

         console.log('关闭失败：', error)

       } else {

         P = new SerialPort(portConfig)

         P?.write('SIR\r\n', 'ascii')//告诉秤端开始发送信息,具体看每个秤的配置,有的不需要

         P.on('data', (data) => {

           //接收到的data为Buffer类型,直接转为字符串就可以使用了

           mainWindow.webContents.send('readingData', data.toString())

         })

       }

     })

   } else {

     P = new SerialPort(portConfig)

     P?.write('SIR\r\n', 'ascii')

     P.on('data', (data) => {

       mainWindow.webContents.send('readingData', data.toString())

     })

   }

 })

解析数据

 <!--渲染进程解析数据-->

 <template>

   <div class="weight-con">

     <div class="weight-con-main">

       <div>

         <el-text class="wei-title" type="primary">毛<br />重</el-text>

       </div>

       <div class="weight-panel">

         <el-text id="wei-num">{{ weightNum!.toFixed(2) }}</el-text>

         <div class="weight-con-footer">当前最大称重：600公斤</div>

       </div>

       <div>

         <el-text class="wei-title" type="primary">公<br />斤</el-text>

       </div>

     </div>

   </div>

 </template>

 ​

 <script setup lang="ts">

 import { weightModel } from '@/utils/WeightReader'

 const emits = defineEmits(['zeroChange'])

 const weightNum = defineModel<number>()

 window.electron.ipcRenderer.on('readingData', (_, data: string) => {

   //渲染进程接收到主进程数据,根据环境变量解析数据

   weightNum.value = weightModel[import.meta.env.VITE_MODE](data)

   if (weightNum.value == 0) {

     emits('zeroChange')

   }

 })

 </script>

 //weightReader.ts 解析配置

 export type Mode = 'model1' | 'model2'

 let str = ''

 export const weightModel = {

   model1: (weightStr: string) => {

     const rev = weightStr.split('').reverse().join('')

     return +rev.replace('=', '')

   },

   module2: (weightStr: string) => {

     str += weightStr

     if (str.match(/S\s+[A-Za-z]\s*(-?\d*.?\d+)\s*kg/g)) {

       const num = str.match(/S\s+[A-Za-z]\s*(-?\d*.?\d+)\s*kg/m)![1]

       str = ''

       return Number(num)

     } else {

       return 0

     }

   }

 }

完活~下班!

JSON是一种轻量级的数据交换格式，基于ECMAScript的一个子集设计，采用完全独立于编程语言的文本格式来表示数据。它易于人类阅读和编写，同时也便于机器解析和生成，这使得JSON在数据交换中具有高效性。‌

JSON也就成了每一个程序员每天都要使用一个小类库。无论你使用的谷歌的gson，阿里巴巴的fastjson，框架自带的jackjson，还是第三方的hutool的json等。总之，每天都要和他打交道。

但是，却在阴沟里翻了船。

1、平平无奇的接口

 /**

     * 获取vehicleinfo 信息

     *

     * @RequestParam vehicleId

     * @return Vehicle的json字符串

     */

    String loadVehicleInfo(Integer vehicleId);

该接口就是通过一个vehicleId参数获取Vehicle对象，返回的数据是Vehicle的JSON字符串，也就是将获取的对象信息序列化成JSON字符串了。

2、无懈可击的引用

String jsonStr = auctVehicleService.loadVehicleInfo(freezeDetail.getVehicle().getId());

if (StringUtils.isNotBlank(jsonStr)) {

    Vehicle vehicle = JSON.parseObject(jsonStr, Vehicle.class);

    if (vehicle != null) {

        // 后续省略 ... 

    }

}

看似无懈可击的引用，隐藏着魔鬼。为什么无懈可击，因为做了健壮性的判断，非空字符串、非空对象等的判断，根除了空指针异常。

但是，魔鬼隐藏在哪里呢？

3、故障引发

线上直接出现类似的故障（此报错信息为线下模拟）。

现在测试为什么没有问题：主要的测试了基础数据，测试的数据中恰好没有Date 类型的数据，所以线下没有测出来。

4、故障原因分析

从报错日志可以看出，是因为日期类型的参数导致的。Mar 24, 2025 1:23:10 PM 这样的日期格式无法使用Fastjson解析。

深入代码查看：

@Override

public String loadVehicleInfo(Integer vehicleId) {

    String key = VEHICLE_KEY + vehicleId;

    Object obj = cacheService.get(key);



    if (null != obj && StringUtils.isNotEmpty(obj.toString())

            && !"null".equals(obj.toString())) {

        String result = (String)obj;

        return result;

    }



    String json = null;

    try {

        Vehicle vInfo = overrideVehicleAttributes(vehicleId);

        // 使用了Gson序列化对象

        json = gson.toJson(vInfo);

        cacheService.setExpireSec(key, gson.toJson(vInfo), 5 * 60);

    } catch (Exception e) {

        cacheService.setExpireSec(key, "", 1 * 60);

    } finally {

    }



    return json;

}

原来接口的实现里面采用了谷歌的Gson对返回的对象做了序列化。调用的地方又使用了阿里巴巴的Fastjson发序列化，导致参数解析异常。

完蛋，上榜是要被扣工资的！！！

5、小结

问题虽小，但是影响却很大。坊间一直讨论着，程序员为什么不能写出没有bug的程序。这也许是其中的一种答案吧。

肉疼，被扣钱了！！！

--END--

喜欢就点赞收藏，也可以关注我的微信公众号：编程朝花夕拾

它像一个锈迹斑斑的铁柱，挪了它，会立马塌一片房。不挪它，又不敢在上面推陈出新。如今是一边定钉子加固，一边试探着放一把椅子，太难了……

年会如期进行，在今年严峻的经济形势下，公司今年的营收和利润，相比去年都有大于30%的增长。这主要得益于老板有个原则：员工要比公司挣得多。也就是今年公司增幅10%，员工收入也要比去年增10%。但是，这个增长不是针对所有人，而是那些挣钱的部门。

老板拉来一堆现金，在年会现场分发。张三，3万；李四，13万；王五25万。销售1部，10万；客服2部，5万……很遗憾，IT研发部，不管是团队还是个人，都榜上无名。

不得不说，确实存在这么一个现象，销售类的岗位是盈利部门，像行政、人力、财务这类属于成本部门。而研发类的岗位，则视情况而定。可以是盈利部门，也可以是成本部门。

这个技术部几十个人，其中老员工很多。这里说的老员工，一方面是指在公司待得久，入职七、八年的大有人在。另一方面，年龄也都很大，40岁的也不在少数。公司很重视老员工，常将入职10多年的立为榜样，这让新员工入职后，感到不可思议以及安全感十足。

很多技术部老人看到发奖金，都会很失落。他们说，每年都这样，热闹是别人的，和自己没关系，连保洁、保安都有个“勤勤恳恳奖”，而程序员啥都没有。干技术没有前途。

作为刚入职的员工，我了解的不是很多，不过也稍微有点旁观者的视角。

公司对于技术部很有成见。各个部门也都有意见，尤其是老板。首先体现在系统的脆弱性上，基本上每年在最关键的营销活动时，服务都会宕机。每次宕机，老板都很着急，事后想让技术部避免此类情况再次发生。而技术部每次都有理由，也会提出新的解决方案。 老板配合技术部，从云服务器改为自建机房，从自建机房又迁移上云服务。

我来公司后，经历过两次宕机。第一次是一个大型活动，技术部说本来是没事的，结果因为运营人员在活动还没结束，就登上后台去查看汇总数据。这个汇总，会导致大量实时计算，结果数据库就顶不住了，停服务也停不掉，死机后数小时才重启成功。

领导说既然是数据库差，那就买数据库。技术部讨论后，感觉不能买。买多少？如果买了之后，还出现问题，那么就会处于舆论的被动面。

第二次，不算是宕机，只是限流。就是很多人来访问，将一部分人挡在外面。体现在app上是一直弹出500错误、服务器内部错误的提示。弄得营销人员都不敢推广了。来了很多人，进不了门，错失很多客源，浪费了营销成本。

后来，技术部又开始总结。原因是APP在一个页面调用了12个不同的接口，而且还有一个接口被连续调用了35次。这导致数据库压力加大，直接100%。幸好禁止用户访问，才没有崩溃。

技术部总监很着急。但是这个总监是App开发出身，不了解服务端。服务出问题了，他就去找后端开发。后端开发者感觉，架构设计是你总监的事情。我就算干好了，那也是你的功劳。因此不优化是本分，优化是情分，有些消极和抵触。

让各个部门吐槽的，还有跟技术部提需求。技术部一直说活多，排不开，响应不了需求。但是，很明显多数人，看起来并不忙，也没有人加班。于是，这几个业务部门领导一碰头，发现都没有开发他们的需求。那他们忙什呢？其实需求提到总监那里，当总监去安排任务时，结果安排不下去，各个组都说自己很忙。最后，总监就向上反馈说自己部门的人都很忙。实际上，可能是几个组长很忙，忙的很烦，不愿接需求，而组员并没有事情做。

整体情况就是这样，老技术们，感觉自己很辛苦，老板也不加钱。不加钱，我没有优化系统的动力，而且你也没有具体的详细策略，出架构那不是我的职责。老板感觉技术部问题频出，系统不稳定，不愿加钱。你干出成绩我才加钱，比如做到今年不宕机，原来需要100万的成本，通过你们技术研发，成本降低到50万。这才叫成绩。

技术：不加钱，我没法努力。老板：干不好，怎么加钱？ 两者陷入如此的循环。

老板为了解决技术部的问题，就经常给技术部换领导。因为你告诉老板，宕机的原因是一个接口被调用30多次，他听不懂，也没有解决方案。要钱、要人都好办，你说接口调用太多，他懵了。他只能找一个能对得上话的人去解决。技术部内部是找不出来的，他认为如果存在这样的人，问题就不会发生了。实际上，技术部里的人，都觉着自己能解决，但是前提得加钱。多少钱办多少事，否则我就静止不动，装傻充愣。

结果，就空降了很多领导，换一个不出成果，换一个还是没有起色。但是，每一任领导都会推翻上一位的设计。比如云服务有问题，那我们就自己建机房。下一任领导来了，听说自己的机房不行？我们上云服务不就解决了！这就造成技术部架构经常变，也没有什么积累。更严重的是，员工也倦了，变来变去，反反复复，再有新的改革措施，大家也不愿认真执行了。

并且，在这个过程中，业务还是不断积累和发展的。这也堆积了形形色色的病态业务系统。而这些系统，只有老员工能掌握，里面的机关埋伏，根本没有文档，全在他们的脑子里。想改什么东西，复杂不复杂，里面到底怎么个逻辑，老技术说啥就是啥。你想维持生命，又不能让老员工过于动荡，否则会导致业务断层。

倒是也会新来一些空降的技术领导。所有的空降领导，都能发现问题所在。问题大家都知道，实习生都看得出来。 比如缺乏技术领导力，团队没有激励机制，缺乏考核流程，技术债积累严重，技术体系稳定性缺失，业务混乱，人员消极等等。

但新领导也只能做一些表面上的改善。比如，基层管理说员工都不听他的，多次强调要交周报，底下员工就是不交，导致自己不知道他们每周都在干什么。空降领导说，周报写不好，扣工资，看他们交不交。稳定性缺失？把稳定性纳入考核，谁写的代码不稳定，扣工资。说一直忙还不加班？压缩工期，原定10天的任务，让6天干完，这不就忙起来了。 对于系统BUG多，领导说好解决，发现bug，按照数量扣工资，肯定就没有bug了。

实际上这是一种从末端治理的方案，是对洪水的围堵而非疏通。软件系统的配合是复杂的，更需要从源头开始治理。 发现bug扣程序员的工资，属于问题倒推的行为。Bug需要界定是哪方产生的，是单纯代码逻辑问题，还是产品规则问题，还是用户操作方式问题，或者是偶然问题。领导说：那就扣所有参与成员的工资，这样大家都会紧绷一根弦，谁都会为了没有bug而努力。

另外，功能还有复杂和简单之分。一个简单的版本，比如修改个提示语，可能产生不了bug。但是，如果是一项复杂的业务，比如写一个机器人对战，可能会有很多bug。还有，考核是不是应该和职级和工资挂钩？月薪2万的人和月薪5000的，干同一项任务，是不是应该有不同的要求。领导说：有意见？有意见可以去没意见的地方工作。

这又是一个新的轮回，让过于散漫的老技术部，又开始变得剑拔弩张起来。他们将面临新的技术架构，考核体系，工作方式。至于这一轮能给公司带来什么，或许只有时间才能给出答案。

而这个老技术部门的困境，到底能不能走出来，又该如何走出来？

本故事纯属虚构，如有雷同，实属巧合。

前言

2025年伊始，科技界的风云人物们——从英伟达的黄仁勋到OpenAI的山姆·奥特曼，再到机器学习领域的泰斗吴恩达不约而同地将目光聚焦于一个关键词：AI Agent（即智能体，若想深入了解，可阅读我的文章《一文读懂2025核心概念 AI Agent：科技巨头都在布局的未来赛道》）。然而，对于AI Agent的前景，持怀疑态度的人可能会问：“大模型只是个能完成问答的概率模型，它哪来的行为能力？又怎能摇身一变成为AI Agent呢？” 这个问题的答案，正隐藏在我们今天要探讨的 Function Calling（函数调用） 技术之中！

一、 什么是大模型的 Function Calling 技术？

Function Calling 是一种让大语言模型能够调用外部函数或工具的技术。简单来说，就是让大模型不仅能理解和生成文本，还能根据用户的需求，调用特定的 API 或工具来完成更复杂的任务。

举个例子：

• 用户：“帮我订一张明天从北京到上海的机票。”
• 不具备Function Calling的大模型：回复“好的，我会帮您订票。”，但无法真正执行。
• 具备 Function Calling 的大模型：可以调用机票预订 API，获取航班信息，并完成订票操作。

二、 Function Calling 和 AI Agent 的关系

AI Agent 是指能够自主感知环境、进行决策和执行动作的智能体。Function Calling 是构建强大 AI Agent 的关键技术之一，它为 AI Agent 提供了以下能力：

• 连接现实世界：  通过调用外部 API，AI Agent 可以获取实时信息、操作外部系统，从而与现实世界进行交互。
• 执行复杂任务：  通过组合调用不同的函数，AI Agent 可以完成更复杂、更个性化的任务，例如旅行规划、日程安排等。
• 提升效率和准确性：  利用外部工具的强大功能，AI Agent 可以更高效、更准确地完成任务，例如数据分析、代码生成等。

从上述分析中可知要开发智能体，必须用到大模型的Function Calling技术。要让大模型调用Function Calling功能，必须提供大模型相应功能的函数。

为了更直观感受大模型Function Calling技术,我们将利用DeepSeek大模型从0到1开发天气助手智能体，可以实时查询天气状态并给我们提供穿衣建议等~

三、心知天气 + Python + DeepSeek开发天气预报智能体

3.1 心知天气注册及API key获取方法

为了能够使用Python代码获得实时的天气情况，我们这里需要用到心知天气的的API:

1. 打开心知天气的官网，注册登录并点击控制台:

2. 在控制台左侧产品管理栏中点击添加产品

3. 申请免费版的API，点击左侧免费版，就可以看到API私钥了：

4. 利用python requests库调用API获得天气情况（免费版的只能得到天气现象、天气现象代码和气温 3项数据）

请提前安装requests sdk: pip install requests

import requests



url = "https://api.seniverse.com/v3/weather/now.json"



params = {

    "key": "",  # 填写你的私钥

    "location": "北京",  # 你要查询的地区可以用代号，拼音或者汉字，文档在官方下载，这里举例北京

    "language": "zh-Hans",  # 中文简体

    "unit": "c",  # 获取气温

}



response = requests.get(url, params=params)  # 发送get请求

temperature = response.json()  # 接受消息中的json部分

print(temperature['results'][0]['now'])  # 输出接收到的消息进行查看

5. 将请求天气的代码封装成可以指定查询地点的函数:

import requests



def get_weather(loc):

    url = "https://api.seniverse.com/v3/weather/now.json"

    params = {

        "key": "", #填写你的私钥

        "location": loc,

        "language": "zh-Hans",

        "unit": "c",

    }

    response = requests.get(url, params=params)

    temperature = response.json()

    return temperature['results'][0]['now']

3.2 DeepSeek API Key注册方法

Function Calling 适用于模型规模大于30B的模型，本次分享我们使用DeepSeek-V3模型。按如下方法注册获得DeepSeek-V3 API Key(Deep-V3 API 访问教程请看文章DeepSeek大模型API实战指南):

1. 进入DeepSeek官网，点击API 开放平台：

2. 注册并充值tokens后(deepseek的tokens还是相当便宜的，10元可以用好久)，点击左边栏API Keys生成API Key:

3. 利用python openai库访问deepseek (这里openai库定义的是请求数据格式，并不是说deepseek是基于openai构造的`)

# 请提前安装openai sdk: pip install openai



from openai import OpenAI



client = OpenAI(api_key="你创建的api key", base_url="https://api.deepseek.com")



response = client.chat.completions.create(

    model="deepseek-chat", # 指定deepseek-chat, deepseek-chat对应deepseek-v3, deepseek-reasoner对应deepseek-r1

    messages=[

        {"role": "system", "content": "You are a helpful assistant"}, #指定系统背景

        {"role": "user", "content": "Hello"}, #指定用户提问

    ],

    stream=False

)



print(response.choices[0].message.content)

3.3 Function Calling准备: 让大模型理解函数

准备好外部函数之后，非常重要的一步是将外部函数的信息以某种形式传输给大模型，让大模型理解函数的作用。大模型需要特定的字典格式对函数进行完整描述, 字典描述包括:

• name:函数名称字符串
• description: 描述函数功能的字符串，大模型选择函数的核心依据
• parameters: 函数参数, 要求遵照JSON Schema格式输入，JSON Schema格式请参照JSON Schema格式详解

对于上面的get_weather函数, 我们创建如下字典对其完整描述:

get_weather_function = {

    'name': 'get_weather',

    'description': '查询即时天气函数，根据输入的城市名称，查询对应城市的实时天气',

    'parameters': {

        'type': 'object',

        'properties': { #参数说明

            'loc': {

                'description': '城市名称',

                'type': 'string'

            }

        },

        'required': ['loc']  #必备参数

    }

}

完成对get_weather函数描述后，还需要将其加入tools列表，用于告知大模型可以使用哪些函数以及这些函数对应的描述，并在可用函数对象中记录一下：

tools = [

    {

        "type": "function",

        "function":get_weather_function

    }

]



available_functions = {

    "get_weather": get_weather,

}

3.4 Function calling 功能实现

完成一系列基础准备工作之后，接下来尝试与DeepSeek-V3大模型对话调用Function calling功能(分步教程代码在 codecopy.cn/post/ir801w ，完整优化代码在codecopy.cn/post/c80rrk ）:

1. 实例化客户端并创建如下messages

# 实例化客户端

client = OpenAI(api_key=你的api_key, 

                base_url="https://api.deepseek.com")



messages=[

    {"role": "user", "content": "请帮我查询北京地区今日天气情况"}

]

2. 测试一下如果只输入问题不输入外部函数,模型是不知道天气结果的，只会告诉我们如何获得实时天气

response = client.chat.completions.create(

        model="deepseek-chat",

        messages=messages 

    )

print(response.choices[0].message.content)

3. 接下来尝试将函数相关信息输入给Chat模型，需要额外设置两个参数，首先是tools参数, 用于申明外部函数库, 也就是我们上面定义的tools列表对象。其次是可选参数tool_choice参数，该参数用于控制模型对函数的选取，默认值为auto, 表示会根据用户提问自动选择要执行函数，若想让模型在本次执行特定函数不要自行挑选，需要给tool_choice参数赋予{"name":"functionname"}值，这时大模型就会从tools列表中选取函数名为functionname的函数执行。这里我们考验一下模型的智能性，让模型自动挑选函数来执行:

response = client.chat.completions.create(

    model="deepseek-chat",  

    messages=[

        {"role": "user", "content": "请帮我查询北京地区今日天气情况"}

    ],

    tools=tools,

)



print(response.choices[0].message)

观察现在response返回的结果, 我们发现message中的content变为空字符串, 增加了一个tool_calls的list, 如图红框所示，该list就包含了当前调用外部函数的全部信息:

我们输出一下toll_calls列表项中的function内容，可以看到大模型自动帮我们选择了要执行的函数get_weather，并告诉我们要传递的参数{loc:北京}。,

response_message = response.choices[0].message

print(response_message.tool_calls[0].function)

4. 下一步将大模型生成的函数参数输入大模型选择的函数并执行（注意大模型不会帮我们自动调用函数，它只会帮我们选择要调用的函数以及生成函数参数），通过上面定义的available_functions对象找到具体的函数，并将大模型返回的参数传入（这里 ** 是一种便捷的参数传递方法，该方法会将字典中的每个key对应的value传输到同名参数位中）,可以看到天气函数成功执行:

# 获取函数名称

function_name = response_message.tool_calls[0].function.name



# 获得对应函数对象

function_to_call = available_functions[function_name]



# 获得执行函数所需参数

function_args = json.loads(response_message.tool_calls[0].function.arguments)



# 执行函数

function_response = function_to_call(**function_args)



print(function_response)

5. 在调用天气函数得到天气情况后，将天气结果传入mesages列表中并发送给大模型，让大模型理解上下文。函数执行结果的message是tool_message类型（这部分有点绕，可以看整体对于message类型有疑问的请看我的文章DeepSeek大模型API实战指南， 里面有详细的参数指南）。

首先将大模型关于选择函数的回复response_message内容解析后传入messages列表中

print(response_message.model_dump())

messages.append(response_message.model_dump()) 

解析结果如下:

{

	'content': '',

	'refusal': ,

	'role': 'assistant',

	'annotations': ,

	'audio': ,

	'function_call': ,

	'tool_calls': [{

		'id': 'call_0_8feaa367-c274-4c84-830f-13b49358a231',

		'function': {

			'arguments': '{"loc":"北京"}',

			'name': 'get_weather'

		},

		'type': 'function',

		'index': 0

	}]

}

然后再将函数执行结果作为tool_message并与response_message关联后传入messages列表中:

messages.append({

    "role": "tool",

    "content": json.dumps(function_response), # 将回复的字典转化为json字符串

    "tool_call_id": response_message.tool_calls[0].id # 将函数执行结果作为tool_message添加到messages中, 并关联返回执行函数内容的id

})

6. 接下来，再次调用Chat模型来围绕messages进行回答。需要注意的是，此时不再需要向模型重复提问，只需要简单的将我们已经准备好的messages传入Chat模型即可：

second_response = client.chat.completions.create(

    model="deepseek-chat",

    messages=messages)



print(second_response.choices[0].message.content)

下面看大模型的输出结果，很明显大模型接收到了函数执行的结果，并进一步处理得到输出，同时天气和气温的输出也是正确的，这样我们就基于function calling技术完成一个简单的智能体了！

3.5 代码优化

以上步骤详细描述了Fucntion Calling的技术细节，执行流程图如下：

开发一个智能体需要将上面流程串起来，下一步我们编写一个能够自动执行外部函数调用的Chat智能体函数， 参数messages为输入到Chat模型的messages参数对象, 参数api_key为调用模型的API-KEY ,参数tools设置为包含全部外部函数的列表对象, 参数model默认为deepseek-chat , 该函数返回结果为大模型根据function calling内容的回复, 函数的具体代码如下:

def run_conv(messages,

             api_key,

             tools=,

             functions_list=,

             model="deepseek-chat"):

    user_messages = messages



    client = OpenAI(api_key=api_key,

                    base_url="https://api.deepseek.com")



    # 如果没有外部函数库，则执行普通的对话任务

    if tools == :

        response = client.chat.completions.create(

            model=model,

            messages=user_messages

        )

        final_response = response.choices[0].message.content



    # 若存在外部函数库，则需要灵活选取外部函数并进行回答

    else:

        # 创建外部函数库字典

        available_functions = {func.__name__: func for func in functions_list}



        # 创建包含用户问题的message

        messages = user_messages



        # first response

        response = client.chat.completions.create(

            model=model,

            messages=user_messages,

            tools=tools,

        )

        response_message = response.choices[0].message



        # 获取函数名

        function_name = response_message.tool_calls[0].function.name

        # 获取函数对象

        fuction_to_call = available_functions[function_name]

        # 获取函数参数

        function_args = json.loads(response_message.tool_calls[0].function.arguments)



        # 将函数参数输入到函数中，获取函数计算结果

        function_response = fuction_to_call(**function_args)



        # messages中拼接first response消息

        user_messages.append(response_message.model_dump())



        # messages中拼接外部函数输出结果

        user_messages.append(

            {

                "role": "tool",

                "content": json.dumps(function_response),

                "tool_call_id": response_message.tool_calls[0].id

            }

        )



        # 第二次调用模型

        second_response = client.chat.completions.create(

            model=model,

            messages=user_messages)



        # 获取最终结果

        final_response = second_response.choices[0].message.content



    return final_response

以上函数的流程就十分清晰啦，调用该函数测试一下结果~

ds_api_key = '你的api key'

messages = [{"role": "user", "content": "请问上海今天天气如何？"}]

get_weather_function = {

    'name': 'get_weather',

    'description': '查询即时天气函数，根据输入的城市名称，查询对应城市的实时天气',

    'parameters': {

        'type': 'object',

        'properties': {  # 参数说明

            'loc': {

                'description': '城市名称',

                'type': 'string'

            }

        },

        'required': ['loc']  # 必备参数

    }

}

tools = [

    {

        "type": "function",

        "function": get_weather_function

    }

]

final_response = run_conv(messages=messages,

         api_key=ds_api_key,

         tools=tools,

         functions_list=[get_weather])

print(final_response)

四、总结与展望

本文我们详细讲解了大模型 function calling技术并基于该技术开发了天气智能体。Function Calling技术是AI Agent实现的关键，它让大模型不再只是简单的聊天回复，更可以"上天入地”完成各种各样的事。

然而在开发过程中我们也发现，function calling 技术开发过程冗长，需要编写相应的能力函数，有没有什么办法可以做到函数复用或简化开发呢，这就需要用到2025年最流行的Agent开发技术——MCP协议，什么是MCP协议呢？我们下一篇文章给大家分享~

感兴趣大家可关注微信公众号：大模型真好玩，工作开发中的大模型经验、教程和工具免费分享，大家快来看看吧~

作者：大模型真好玩
来源：juejin.cn/post/7486323379474645027

真快啊！Java 24 这两天已经正式发布啦！这是自 Java 21 以来的第三个非长期支持版本，和 Java 22、Java 23一样。

下一个长期支持版是 Java 25，预计今年 9 月份发布。

Java 24 带来的新特性还是蛮多的，一共 24 个。Java 23 和 Java 23 都只有 12 个，Java 24的新特性相当于这两次的总和了。因此，这个版本还是非常有必要了解一下的。

下图是从 JDK8 到 JDK 24 每个版本的更新带来的新特性数量和更新时间：

我在昨天晚上详细看了一下 Java 24 的详细更新，并对其中比较重要的新特性做了详细的解读，希望对你有帮助！

本文内容概览：

JEP 478: 密钥派生函数 API（预览）

密钥派生函数 API 是一种用于从初始密钥和其他数据派生额外密钥的加密算法。它的核心作用是为不同的加密目的（如加密、认证等）生成多个不同的密钥，避免密钥重复使用带来的安全隐患。 这在现代加密中是一个重要的里程碑，为后续新兴的量子计算环境打下了基础

通过该 API，开发者可以使用最新的密钥派生算法（如 HKDF 和未来的 Argon2）：

// 创建一个 KDF 对象，使用 HKDF-SHA256 算法

KDF hkdf = KDF.getInstance("HKDF-SHA256"); 



// 创建 Extract 和 Expand 参数规范

AlgorithmParameterSpec params =

    HKDFParameterSpec.ofExtract()

                     .addIKM(initialKeyMaterial) // 设置初始密钥材料

                     .addSalt(salt)             // 设置盐值

                     .thenExpand(info, 32);     // 设置扩展信息和目标长度



// 派生一个 32 字节的 AES 密钥

SecretKey key = hkdf.deriveKey("AES", params);



// 可以使用相同的 KDF 对象进行其他密钥派生操作

JEP 483: 提前类加载和链接

在传统 JVM 中，应用在每次启动时需要动态加载和链接类。这种机制对启动时间敏感的应用（如微服务或无服务器函数）带来了显著的性能瓶颈。该特性通过缓存已加载和链接的类，显著减少了重复工作的开销，显著减少 Java 应用程序的启动时间。测试表明，对大型应用（如基于 Spring 的服务器应用），启动时间可减少 40% 以上。

这个优化是零侵入性的，对应用程序、库或框架的代码无需任何更改，启动也方式保持一致，仅需添加相关 JVM 参数（如 -XX:+ClassDataSharing）。

JEP 484: 类文件 API

类文件 API 在 JDK 22 进行了第一次预览（JEP 457），在 JDK 23 进行了第二次预览并进一步完善（JEP 466）。最终，该特性在 JDK 24 中顺利转正。

类文件 API 的目标是提供一套标准化的 API，用于解析、生成和转换 Java 类文件，取代过去对第三方库（如 ASM）在类文件处理上的依赖。

// 创建一个 ClassFile 对象，这是操作类文件的入口。

ClassFile cf = ClassFile.of();

// 解析字节数组为 ClassModel

ClassModel classModel = cf.parse(bytes);



// 构建新的类文件，移除以 "debug" 开头的所有方法

byte[] newBytes = cf.build(classModel.thisClass().asSymbol(),

        classBuilder -> {

            // 遍历所有类元素

            for (ClassElement ce : classModel) {

                // 判断是否为方法 且 方法名以 "debug" 开头

                if (!(ce instanceof MethodModel mm

                        && mm.methodName().stringValue().startsWith("debug"))) {

                    // 添加到新的类文件中

                    classBuilder.with(ce);

                }

            }

        });

JEP 485: 流收集器

流收集器 Stream::gather(Gatherer) 是一个强大的新特性，它允许开发者定义自定义的中间操作，从而实现更复杂、更灵活的数据转换。Gatherer 接口是该特性的核心，它定义了如何从流中收集元素，维护中间状态，并在处理过程中生成结果。

与现有的 filter、map 或 distinct 等内置操作不同，Stream::gather 使得开发者能够实现那些难以用标准 Stream 操作完成的任务。例如，可以使用 Stream::gather 实现滑动窗口、自定义规则的去重、或者更复杂的状态转换和聚合。 这种灵活性极大地扩展了 Stream API 的应用范围，使开发者能够应对更复杂的数据处理场景。

基于 Stream::gather(Gatherer) 实现字符串长度的去重逻辑：

var result = Stream.of("foo", "bar", "baz", "quux")

                   .gather(Gatherer.ofSequential(

                       HashSet::new, // 初始化状态为 HashSet,用于保存已经遇到过的字符串长度

                       (set, str, downstream) -> {

                           if (set.add(str.length())) {

                               return downstream.push(str);

                           }

                           return true; // 继续处理流

                       }

                   ))

                   .toList();// 转换为列表



// 输出结果 ==> [foo, quux]

JEP 486: 永久禁用安全管理器

JDK 24 不再允许启用 Security Manager，即使通过 java -Djava.security.manager命令也无法启用，这是逐步移除该功能的关键一步。虽然 Security Manager 曾经是 Java 中限制代码权限（如访问文件系统或网络、读取或写入敏感文件、执行系统命令）的重要工具，但由于复杂性高、使用率低且维护成本大，Java 社区决定最终移除它。

JEP 487: 作用域值 （第四次预览）

作用域值（Scoped Values）可以在线程内和线程间共享不可变的数据，优于线程局部变量，尤其是在使用大量虚拟线程时。

final static ScopedValue<...> V = new ScopedValue<>();



// In some method

ScopedValue.where(V, <value>)

           .run(() -> { ... V.get() ... call methods ... });



// In a method called directly or indirectly from the lambda expression

... V.get() ...

作用域值允许在大型程序中的组件之间安全有效地共享数据，而无需求助于方法参数。

JEP 491: 虚拟线程的同步而不固定平台线程

优化了虚拟线程与 synchronized 的工作机制。 虚拟线程在 synchronized 方法和代码块中阻塞时，通常能够释放其占用的操作系统线程（平台线程），避免了对平台线程的长时间占用，从而提升应用程序的并发能力。 这种机制避免了“固定 (Pinning)”——即虚拟线程长时间占用平台线程，阻止其服务于其他虚拟线程的情况。

现有的使用 synchronized 的 Java 代码无需修改即可受益于虚拟线程的扩展能力。 例如，一个 I/O 密集型的应用程序，如果使用传统的平台线程，可能会因为线程阻塞而导致并发能力下降。 而使用虚拟线程，即使在 synchronized 块中发生阻塞，也不会固定平台线程，从而允许平台线程继续服务于其他虚拟线程，提高整体的并发性能。

JEP 493：在没有 JMOD 文件的情况下链接运行时镜像

默认情况下，JDK 同时包含运行时镜像（运行时所需的模块）和 JMOD 文件。这个特性使得 jlink 工具无需使用 JDK 的 JMOD 文件就可以创建自定义运行时镜像，减少了 JDK 的安装体积（约 25%）。

说明：

• Jlink 是随 Java 9 一起发布的新命令行工具。它允许开发人员为基于模块的 Java 应用程序创建自己的轻量级、定制的 JRE。


• JMOD 文件是 Java 模块的描述文件，包含了模块的元数据和资源。

JEP 495: 简化的源文件和实例主方法（第四次预览）

这个特性主要简化了 main 方法的的声明。对于 Java 初学者来说，这个 main 方法的声明引入了太多的 Java 语法概念，不利于初学者快速上手。

没有使用该特性之前定义一个 main 方法：

public class HelloWorld {

    public static void main(String[] args) {

        System.out.println("Hello, World!");

    }

}

使用该新特性之后定义一个 main 方法：

class HelloWorld {

    void main() {

        System.out.println("Hello, World!");

    }

}

进一步简化（未命名的类允许我们省略类名）

void main() {

   System.out.println("Hello, World!");

}

JEP 497: 量子抗性数字签名算法 (ML-DSA)

JDK 24 引入了支持实施抗量子的基于模块晶格的数字签名算法 （Module-Lattice-Based Digital Signature Algorithm, ML-DSA），为抵御未来量子计算机可能带来的威胁做准备。

ML-DSA 是美国国家标准与技术研究院（NIST）在 FIPS 204 中标准化的量子抗性算法，用于数字签名和身份验证。

JEP 498: 使用 sun.misc.Unsafe 内存访问方法时发出警告

JDK 23(JEP 471) 提议弃用 sun.misc.Unsafe 中的内存访问方法，这些方法将来的版本中会被移除。在 JDK 24 中，当首次调用 sun.misc.Unsafe 的任何内存访问方法时，运行时会发出警告。

这些不安全的方法已有安全高效的替代方案：

• java.lang.invoke.VarHandle ：JDK 9 (JEP 193) 中引入，提供了一种安全有效地操作堆内存的方法，包括对象的字段、类的静态字段以及数组元素。


• java.lang.foreign.MemorySegment ：JDK 22 (JEP 454) 中引入，提供了一种安全有效地访问堆外内存的方法，有时会与 VarHandle 协同工作。

这两个类是 Foreign Function & Memory API（外部函数和内存 API） 的核心组件，分别用于管理和操作堆外内存。Foreign Function & Memory API 在 JDK 22 中正式转正，成为标准特性。

import jdk.incubator.foreign.*;

import java.lang.invoke.VarHandle;



// 管理堆外整数数组的类

class OffHeapIntBuffer {



    // 用于访问整数元素的VarHandle

    private static final VarHandle ELEM_VH = ValueLayout.JAVA_INT.arrayElementVarHandle();



    // 内存管理器

    private final Arena arena;



    // 堆外内存段

    private final MemorySegment buffer;



    // 构造函数，分配指定数量的整数空间

    public OffHeapIntBuffer(long size) {

        this.arena  = Arena.ofShared();

        this.buffer = arena.allocate(ValueLayout.JAVA_INT, size);

    }



    // 释放内存

    public void deallocate() {

        arena.close();

    }



    // 以volatile方式设置指定索引的值

    public void setVolatile(long index, int value) {

        ELEM_VH.setVolatile(buffer, 0L, index, value);

    }



    // 初始化指定范围的元素为0

    public void initialize(long start, long n) {

        buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,

                       ValueLayout.JAVA_INT.byteSize() * n)

              .fill((byte) 0);

    }



    // 将指定范围的元素复制到新数组

    public int[] copyToNewArray(long start, int n) {

        return buffer.asSlice(ValueLayout.JAVA_INT.byteSize() * start,

                              ValueLayout.JAVA_INT.byteSize() * n)

                     .toArray(ValueLayout.JAVA_INT);

    }

}

JEP 499: 结构化并发（第四次预览）

JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代java.util.concurrent，目前处于孵化器阶段。

结构化并发将不同线程中运行的多个任务视为单个工作单元，从而简化错误处理、提高可靠性并增强可观察性。也就是说，结构化并发保留了单线程代码的可读性、可维护性和可观察性。

结构化并发的基本 API 是StructuredTaskScope，它支持将任务拆分为多个并发子任务，在它们自己的线程中执行，并且子任务必须在主任务继续之前完成。

StructuredTaskScope 的基本用法如下：

    try (var scope = new StructuredTaskScope<Object>()) {

        // 使用fork方法派生线程来执行子任务

        Future<Integer> future1 = scope.fork(task1);

        Future<String> future2 = scope.fork(task2);

        // 等待线程完成

        scope.join();

        // 结果的处理可能包括处理或重新抛出异常

        ... process results/exceptions ...

    } // close

结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。

Java 新特性系列解读

如果你想系统了解 Java 8 以及之后版本的新特性，可以在 JavaGuide 上阅读对应的文章：

比较推荐这几篇：

• Java 11 新特性概览


• Java 17 新特性概览（重要）


• Java 21 新特性概览(重要)

相信大家都跟我一样有这样一个疑问：之前都说虚拟DOM是为了性能，怎么现在又反向宣传了？无虚拟DOM怎么又逆流而上成为了性能的标杆了呢？

下篇文章我们会仔细分析无虚拟DOM与虚拟DOM之间的区别，本篇文章我们先看数据。首先是体积，由于没有了虚拟DOM以及vDOM diff算法，所以体积肯定能小不少。当然不是说无虚拟DOM就彻底不需要diff算法了，我看过同为无虚拟DOM框架的Svelte和Solid源码，无虚拟DOM只是不需要vDOM间的Diff算法，列表之间还是需要diff的。毕竟再怎么编译，你从后端获取到的数组，编译器也不可能预测得到。

那么官方给出的数据是：

虽然没有想象中的那么多，但33.6%也算是小不少了。当然这个数据指的是纯Vapor模式，如果你把虚拟DOM和Vapor混着用的话，体积不仅不会减小反而还会增加。毕竟会同时加载Vapor模式的runtime和虚拟DOM模式的runtime，二者一相加就大了。

Vapor模式指的就是无虚拟DOM模式，如果你不太清楚二者之间有何关联的话，可以看一眼这篇：《无虚拟DOM版Vue为什么叫Vapor》

那性能呢？很多人对体积其实并不敏感，觉得多10K少10k都无所谓，毕竟现在都是5G时代了。所以我们就来看一眼官方公布的性能数据：

从左到右依次为：

• 原生JS：1.01


• Solid：1.09


• Svelte：1.11


• 无虚拟DOM版Vue：1.24


• 虚拟DOM版Vue：1.32


• React：1.55

数字越小代表性能越高，但无论再怎么高都不可能高的过手动优化过的原生JS，毕竟无论什么框架最终打包编译出来的还是JS。不过框架的性能其实已经挺接近原生的了，尤其是以无虚拟DOM著称的Solid和Svelte。但无虚拟DOM版Vue和虚拟DOM版Vue之间并没有拉开什么很大的差距，1.24和1.32这两个数字证明了其实二者的性能差距并不明显，这又是怎么一回事呢？

一个原因是Vue3本来就做了许多编译优化，包括但不限于静态提升、大段静态片段将采用innerHTML渲染、编译时打标记以帮助虚拟DOM走捷径等… 由于本来的性能就已经不错了，所以可提升的空间自然也没多少。

看完上述原因肯定有人会说：可提升的空间没多少可以理解，那为什么还比同为无虚拟DOM的Solid和Svelte差那么多？如果Vapor和Solid性能差不多的话，那可提升空间小倒是说得过去。但要是像现在这样差的还挺多的话，那这个理由是不是就有点站不住脚了？之所以会出现这样的情况是因为Vue Vapor的作者在性能优化和快速实现之间选择了后者，毕竟尤雨溪第一次公布要开始做无虚拟DOM版Vue的时间是在2020年：

而如今已经是2025年了。也就是说如果一个大一新生第一次满心欢喜的听到无虚拟DOM版Vue的消息后，那么他现在大概率已经开始毕业工作了都没能等到无虚拟DOM版Vue的发布。这个时间拖的有点太长了，甚至从Vue2到Vue3都没用这么久。

可以看到Vue3从立项到发布也就不到两年的时间，而Vapor呢？从立项到现在已经将近5年的光阴了，已经比Vue3所花费的时间多出一倍还多了。所以现在的首要目标是先实现出来一版能用的，后面再慢慢进行优化。我们工作不也是这样么？先优先把功能做出来，优化的事以后再说。那么具体该怎么优化呢：

现在的很多渲染逻辑继承自原版Vue3，但无虚拟DOM版Vue可以采用更优的渲染逻辑。而且现在的Vapor是跟着原版Vue的测试集来做的，这也是为了实现和原版Vue一样的行为。但这可能并不是最优解，之后会慢慢去掉一些不必要的功能，尤其是对性能产生较大影响的功能。

往期精彩文章：

• 《尤雨溪：从Vue1到Vue3.6》


• 《无虚拟DOM版Vue为什么叫Vapor？》

先弄清楚leaflet和天地图充当的角色

• leaflet是用来在绘制、交互地图的


• 天地图是纯粹用来当个底图的，相当于在leaflet中底部的一个图层而已


• 进行Marker打点、geojson绘制等操作都是使用leaflet实现

1. 使用天地图当底图

• 在token处填自己的token


• 我这里用的是天地图的影像底图，如果需要可自行更换或添加底图


• 天地图底图网址：lbs.tianditu.gov.cn/server/MapS…


• 只用替换我代码里的天地图链接里的http://{s}.tianditu.com/img_c/里的img_c为我图中圈起来的编号，其他不用动

const token = "填自己的天地图token";

// 底图

const VEC_C ="http://{s}.tianditu.com/img_c/wmts?layer=vec&style=default&tilematrixset=c&Service=WMTS&Request=GetTile&Version=1.0.0&Format=tiles&TileMatrix={z}&TileCol={x}&TileRow={y}&tk=";

// 文字标注

// const CVA_C = "http://{s}.tianditu.com/cia_c/wmts?layer=cva&style=default&tilematrixset=c&Service=WMTS&Request=GetTile&Version=1.0.0&Format=tiles&TileMatrix={z}&TileCol={x}&TileRow={y}&tk=";

let map = L.map("map", {

  minZoom: 3,

  maxZoom: 17,

  center: [34.33213, 109.00945],

  zoomSnap: 0.1,

  zoom: 3.5,

  zoomControl: false,

  attributionControl: false,

  crs: L.CRS.EPSG4326,

});

L.tileLayer(VEC_C + token, {

  zoomOffset: 1,

  subdomains: ["t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7"],

  opacity: 0.2,

}).addTo(map);

// 添加文字标注

// L.tileLayer(CVA_C + token, {

//   tileSize: 256,

//   zoomOffset: 1,

//   subdomains: ["t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7"],

// }).addTo(map);

2. 绘制中国地图geojson

• 这里我需要国的边界和省的边界线颜色不一样，所以用了一个国的geojson和另一个包含省的geojson叠加来实现


• 获取geojson数据网站：datav.aliyun.com/portal/scho…

L.geoJson(sheng, {

 style: {

    color: "#0c9fb8",

    weight: 1,

    fillColor: "#028297",

    fillOpacity: 0.1,

  },

}).addTo(map);

L.geoJson(guo, {

  style: {

    color: "#b8c3c8",

    weight: 2,

    fillOpacity: 0,

  },

}).addTo(map);

3. 更换背景主题色

我的实现思路比较简单粗暴，直接给天地图的图层设置透明度，对div元素设置背景色，如果UI配合，可以叫UI给个遮罩层的背景图，比如我这里就是用了四周有黑边渐变阴影，中间是透明的背景图。

<div id="map"></div>

<div class="mask"></div>



#map {

  height: 100vh;

  width: 100vw;

  background: #082941;

  z-index: 2;

}



.mask {

  width: 100%;

  height: 100%;

  position: absolute;

  left: 0;

  top: 0;

  background: url("./mask.png") no-repeat;

  background-size: 100% 100%;

  z-index: 1;

}

4. 完整代码

• 写自己天地图的token


• 自己下载geojson文件


• 自己看需要搞个遮罩层背景图，不需要就注释掉mask

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

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

    <title>Document</title>

    <link

      href="https://cdn.bootcdn.net/ajax/libs/leaflet/1.9.4/leaflet.css"

      rel="stylesheet"

    />

  </head>

  <style>

    * {

      margin: 0;

      padding: 0;

    }

    #map {

      height: 100vh;

      width: 100vw;

      background: #082941;

      z-index: 2;

    }



    .mask {

      width: 100%;

      height: 100%;

      position: absolute;

      left: 0;

      top: 0;

      background: url("./mask.png") no-repeat;

      background-size: 100% 100%;

      z-index: 1;

    }

  </style>

  <body>

    <div id="map"></div>

    <div class="mask"></div>

  </body>

  <script src="https://cdn.bootcdn.net/ajax/libs/leaflet/1.9.4/leaflet.js"></script>

  <script src="./china.js"></script>

  <script src="./guo.js"></script>



  <script>

    const token = "写自己天地图的token";

    // 底图

    const VEC_C =

      "http://{s}.tianditu.com/img_c/wmts?layer=vec&style=default&tilematrixset=c&Service=WMTS&Request=GetTile&Version=1.0.0&Format=tiles&TileMatrix={z}&TileCol={x}&TileRow={y}&tk=";

    //   文字标注

    // const CVA_C =

    //   "http://{s}.tianditu.com/cia_c/wmts?layer=cva&style=default&tilematrixset=c&Service=WMTS&Request=GetTile&Version=1.0.0&Format=tiles&TileMatrix={z}&TileCol={x}&TileRow={y}&tk=";



    let map = L.map("map", {

      minZoom: 3,

      maxZoom: 17,

      center: [34.33213, 109.00945],

      zoomSnap: 0.1,

      zoom: 3.5,

      zoomControl: false,

      attributionControl: false, //版权控制器

      crs: L.CRS.EPSG4326,

    });

    L.tileLayer(VEC_C + token, {

      zoomOffset: 1,

      subdomains: ["t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7"],

      opacity: 0.2,

    }).addTo(map);

    // L.tileLayer(CVA_C + token, {

    //   tileSize: 256,

    //   zoomOffset: 1,

    //   subdomains: ["t0", "t1", "t2", "t3", "t4", "t5", "t6", "t7"],

    // }).addTo(map);



    L.geoJson(sheng, {

      style: {

        color: "#0c9fb8",

        weight: 1,

        fillColor: "#028297",

        fillOpacity: 0.1,

      },

    }).addTo(map);

    L.geoJson(guo, {

      style: {

        color: "#b8c3c8",

        weight: 2,

        fillOpacity: 0,

      },

    }).addTo(map);

  </script>

</html>

说在前面

最近实现了一个b站插件，可以通过语音来控制播放页面上指定的视频，在语音识别的过程中遇到了需要将中文数字转为阿拉伯数字的情况，在这里分享一下具体事例和处理过程。

功能背景

先介绍一下功能背景，页面渲染的时候会先对视频进行编号处理，具体如下：

比如我们想要播放第4个视频的话，我们只需要说“第4个”，插件就能帮我们选择第四个视频进行播放。

问题描述

功能背景我们已经了解了，那么问题是出在哪里呢？

如上图，这里识别出来的语音文本数字是中文数字，这样跟页面的视频编号无法对应上，因此我们需要实现一个方法来将中文转为阿拉伯数字。

方法实现

1、个位级映射表

const numMap = {

  零: 0,一: 1,壹: 1,二: 2,两: 2,

  三: 3,叁: 3,四: 4,肆: 4,五: 5,

  伍: 5,六: 6,陆: 6,七: 7,柒: 7,

  八: 8,捌: 8,九: 9,玖: 9,

};

2、单位映射表

const unitMap = {

  十: { value: 10, sec: false },

  拾: { value: 10, sec: false },

  百: { value: 100, sec: false },

  佰: { value: 100, sec: false },

  千: { value: 1000, sec: false },

  仟: { value: 1000, sec: false },

  万: { value: 10000, sec: true },

  萬: { value: 10000, sec: true },

  亿: { value: 100000000, sec: true },

  億: { value: 100000000, sec: true }

};

3、处理流程

• 遇到数字：先存起来（比如「三」记作3）

if (hasZero && current > 0) {

  current *= 10;

  hasZero = false;

}

current += numMap[char];

• 遇到单位：
  
  
  
  
  • 如果是十/百/千：把存着的数字乘上倍数
    （如「三百」→3×100=300）
  
  
  
  

  current = current === 0 ? unit.value : current * unit.value;
  
  section += current;
  
  current = 0;
  
  

  
  
  
  
  • 遇到万/亿：先结算当前数字，将当前数字加到总数上
  
  
  
  

  processSection();
  
  section = (section + current) * unit.value;
  
  total += section;
  
  section = 0;
  
  

  
  


• 遇到零：做个标记，提醒下个数字要占位
  （如「三百零五」→300 + 0 +5=305）

if (char === "零") {

  hasZero = true;

  continue;

}

4、完整代码

function chineseToArabic(chineseStr) {

  // 映射表（支持简繁）

  const numMap = {

    零: 0,一: 1,壹: 1,二: 2,两: 2,

    三: 3,叁: 3,四: 4,肆: 4,五: 5,

    伍: 5,六: 6,陆: 6,七: 7,柒: 7,

    八: 8,捌: 8,九: 9,玖: 9,

  };

  //单位映射表

  const unitMap = {

    十: { value: 10, sec: false },

    拾: { value: 10, sec: false },

    百: { value: 100, sec: false },

    佰: { value: 100, sec: false },

    千: { value: 1000, sec: false },

    仟: { value: 1000, sec: false },

    万: { value: 10000, sec: true },

    萬: { value: 10000, sec: true },

    亿: { value: 100000000, sec: true },

    億: { value: 100000000, sec: true }

  };



  let total = 0; // 最终结果

  let section = 0; // 当前小节

  let current = 0; // 当前累加值

  let hasZero = false; // 零标记



  const processSection = () => {

    section += current;

    current = 0;

  };



  for (const char of chineseStr) {

    if (numMap.hasOwnProperty(char)) {

      if (char === "零") {

        hasZero = true;

        continue;

      }



      if (hasZero && current > 0) {

        current *= 10;

        hasZero = false;

      }

      current += numMap[char];

    } else if (unitMap.hasOwnProperty(char)) {

      const unit = unitMap[char];



      if (unit.sec) {

        // 处理万/亿分段

        processSection();

        section = (section + current) * unit.value;

        total += section;

        section = 0;

      } else {

        current = current === 0 ? unit.value : current * unit.value;

        section += current;

        current = 0;

      }

      hasZero = false;

    }

  }



  const last2 = chineseStr.slice(-2)[0];

  const last2Unit = unitMap[last2];

  if (last2Unit) {

    current = (current * last2Unit.value) / 10;

  }

  return total + section + current;

}

功能测试

柒億零捌拾萬

十萬三十

十萬三

二百五

二百零五

八

插件信息

对我上述提到的插件感兴趣的同学可以看下我前面发的这篇文章：

juejin.cn/post/748557…

公众号

关注公众号『 前端也能这么有趣 』，获取更多有趣内容。

发送 加群 还可以加入群聊，一起来学习（摸鱼）吧~

说在后面

🎉 这里是 JYeontu，现在是一名前端工程师，有空会刷刷算法题，平时喜欢打羽毛球 🏸 ，平时也喜欢写些东西，既为自己记录 📋，也希望可以对大家有那么一丢丢的帮助，写的不好望多多谅解 🙇，写错的地方望指出，定会认真改进 😊，偶尔也会在自己的公众号『前端也能这么有趣』发一些比较有趣的文章，有兴趣的也可以关注下。在此谢谢大家的支持，我们下文再见 🙌。

面试官问：“你能接受加班吗？”我脑袋嗡的一声，余音绕梁三日不绝于耳。

那一刻，我简直觉得自己像被突然砸中脑袋，脑袋里嗡的一声，余音绕梁三日。作为一个职场小白，这种问题简直颠覆了我对面试的认知。于是，我一时心血来潮，脱口而出一句：“领导抗揍吗？” 结果，大家猜到了，面试是上午结束的，Offer是当天中午凉的。

如何巧妙回答

“我认为加班是工作中不可避免的一部分，尤其是在一些特殊项目或紧急情况下。我非常热爱我的工作，并且对公司的发展充满信心，因此我愿意为了团队的成功付出额外的努力。当然，我也注重工作效率和时间管理，尽量在正常工作时间内完成任务。如果确实需要加班，我也会根据公司合理的安排，积极的响应。”

作为一名资深的面试官，今天面对这个问题，坐下来和大家聊聊应该怎么回答呢？面试官究竟喜欢怎样的回答？让我们深入分析一下。

面试官的心理

在职场中，想要出色地应对面试，需要具备敏锐的观察力和理解力。学会细致入微地观察，善于捕捉每一个细微的线索，这样才能在面试中游刃有余。懂的察言观色，方能尽显英雄本色。

面试官的考量点

• 评估工作稳定性

面试官提出“能否接受加班”的问题，旨在深入了解求职者的职业稳定性和对加班安排的适应性。这一评估有助于预测求职者入职后的表现和长期留任的可能性。工作稳定性是企业考量员工的关键指标之一，通过这一问题，面试官能够洞察求职者的职业发展规划及其对未来工作的期望。

• 筛选合适的候选人

通过询问加班的接受度，面试官筛选出那些愿意为达成工作目标而投入额外时间和精力的候选人。这种筛选方式有助于确保团队的整体运作效率和协作精神。合适的候选人不仅能快速融入团队，还能显著提升工作效率。因此，面试官借此问题寻找最匹配岗位需求的员工。

• 了解求职者的价值观

面试官还利用这个问题来探查求职者的价值观和工作态度，以此判断他们是否与公司的文化和核心价值观相契合。员工的价值观和态度对公司的长远发展起着至关重要的作用。通过这一询问，面试官能够确保求职者的个人目标与公司的发展方向保持一致，从而促进整体的和谐与进步。

考察的问题的意义

要理解问题的本质……为什么面试官会提出这样的问题？难道是因为你的颜值过高，引发了他的嫉妒？

• 工作态度

面试官通过询问加班的接受度，旨在评估求职者是否展现出积极的工作态度和强烈的责任心。在许多行业中，加班已成为常态，面试官借此问题了解求职者是否愿意在工作上投入额外的时间和精力。积极的工作态度和责任心是职场成功的关键因素，通过这一问题，面试官能够初步判断求职者是否适应高强度的工作环境。

• 岗位匹配度

特定岗位因其工作性质可能需要频繁加班。面试官通过提出加班相关的问题，旨在了解求职者是否能适应这类岗位的工作强度。由于不同岗位对工作强度的要求各异，面试官希望通过这一问题确保求职者对即将承担的角色有明确的认识，从而防止入职后出现期望不一致的情况。

• 抗压能力

加班往往伴随压力，面试官通过这一问题考察求职者的抗压能力和情绪管理技巧。抗压能力对于职场成功至关重要，面试官借此了解求职者在高压环境下的表现，以判断其是否符合公司的需求。

• 公司文化

面试官还利用这个问题来评估求职者对公司加班文化的接受程度，以此判断其价值观是否与公司相符。公司文化对员工的工作体验和满意度有着深远的影响，面试官希望通过这一问题确保求职者能够认同并融入公司文化。

回答的艺术

“知己知彼，百战不殆。”在面试中，回答问题的关键在于展现出积极和正向的态度。

• 积极态度

在回答有关加班的问题时，表达你对工作的热爱和对公司的忠诚，强调你愿意为了团队的成功而付出额外的努力。这种积极的态度不仅展示了你的职业素养和对工作的热情，还能显著提升面试官对你的好感。

例如：“我非常热爱我的工作，并且对公司的发展充满信心。我相信为了实现公司的目标和团队的成功，适当的加班是可以接受的。”

• 灵活性和效率

强调你在时间管理和工作效率上的能力，表明你在确保工作质量的同时，会尽可能减少加班的需求。灵活性和效率是职场中极为重要的技能，面试官可以通过这个问题了解你的实际工作表现。

例如：“我在工作中注重效率和时间管理，通常能够在规定的工作时间内完成任务。当然，如果有特殊情况需要加班，我也会全力以赴。”

• 平衡工作与生活

适当地提到你对工作与生活平衡的重视，并希望公司在安排加班时能够充分考虑到员工的个人需求。平衡工作与生活是职场人士普遍关注的问题，面试官通过这个问题可以了解你的个人需求和期望。

例如：“我非常重视工作与生活的平衡，希望在保证工作效率的同时，也能有足够的时间陪伴家人和进行个人活动。如果公司能够合理安排加班时间，我会非常乐意配合。”

• 适度反问

在回答时，可以适当地向面试官询问关于公司加班的具体情况，以便更全面地了解公司的加班文化和预期。这样的反问可以展现你的主动性和对公司的兴趣，有助于获取更多信息，做出更加明智的回答。

例如：“请问公司通常的加班情况是怎样的？是否有相关的加班补偿或调休安排？”

最后

所谓士为知己者死，遇良将则冲锋陷阵，择良人则共谋天下。在职场这场没有硝烟的战争中，我们每个人都是一名战士，寻找着属于自己的知己和良将。当面试官提出挑战性问题时，我们不仅要展示自己的能力和才华，更要表现出对工作的热爱和对公司的忠诚。

面对“你能接受加班吗？”这样的问题，我们应以积极的态度、灵活的思维和对工作与生活平衡的重视来回应。这样的回答不仅能展示我们的职业素养，还能让我们在众多求职者中脱颖而出，赢得面试官的青睐。

正如士为知己者死，我们在职场中也要找到那个能理解我们、支持我们的知己；遇良将则冲锋陷阵，我们要在优秀的领导下发挥自己的潜能，为公司的发展贡献力量；择良人则共谋天下，我们要与志同道合的同事共同努力，实现职业生涯的辉煌。

总之一句话，在面试中展现出积极向上的形象，不仅能为我们的职业生涯加分，更能让我们在职场上找到属于自己的价值和归属感。让我们以这句话为指引，勇敢地迎接职场的挑战，书写属于自己的辉煌篇章。

npx 和 npm 是 Node.js 生态中两个密切相关的工具，但它们的功能和用途有显著区别：

1. npm（Node Package Manager）

• 定位：Node.js 的包管理工具，用于安装、管理和发布 JavaScript 包。


• 核心功能：
  
  
  
  • 安装依赖：通过 npm install <package> 安装包到本地或全局。
  
  
  • 管理项目依赖：通过 package.json 文件记录依赖版本。
  
  
  • 运行脚本：通过 npm run <script> 执行 package.json 中定义的脚本。
  
  
  • 发布包：通过 npm publish 将代码发布到 npm 仓库。
  
  
  
  


• 示例：
  

  npm install lodash         # 安装 lodash 到本地 node_modules
  
  npm install -g typescript  # 全局安装 TypeScript
  
  npm run start              # 运行 package.json 中的 "start" 脚本
  
  

  
  

2. npx（Node Package Executor）

• 定位：npm 的配套工具，用于直接执行包中的命令，无需全局或本地安装。


• 核心功能：
  
  
  
  • 临时执行包：自动下载远程包并运行，完成后删除。
  
  
  • 运行本地已安装的包：直接调用本地 node_modules/.bin 中的命令。
  
  
  • 切换包版本：指定特定版本运行（如 npx node@14 myscript.js）。
  
  
  
  


• 示例：
  

  npx create-react-app my-app  # 临时下载并运行 create-react-app
  
  npx eslint .                # 运行本地安装的 eslint
  
  npx http-server             # 启动一个临时 HTTP 服务器
  
  

  
  

关键区别

为什么需要 npx？

使用建议

• 用 npm：
  
  管理项目依赖、定义脚本、发布包。


• 用 npx：
  
  运行脚手架工具（如 create-react-app）、临时工具（如 http-server）或本地已安装的命令。

示例场景

# 使用 npm 安装依赖

npm install axios



# 使用 npx 运行一次性工具

npx json-server db.json  # 临时启动一个 REST API 服务器



# 使用 npm 运行脚本（需在 package.json 中定义 "scripts"）

npm run build



# 使用 npx 调用本地已安装的包

npx webpack --config webpack.config.js

通过合理使用 npm 和 npx，可以更高效地管理依赖和执行命令。

1. 官方真的不推荐 Enum 了吗？

1.1 事情的起因

起因是看到 科技爱好者周刊（第 340 期） 里面推荐了一篇文章，说是官方不再推荐使用 enum 语法，原文链接在 An ode to TypeScript enums，大致是说 TS 新出了一个 --erasableSyntaxOnly 配置，只允许使用可擦除语法，但是 enum 不可擦除，因此推断官方已不再推荐使用 enum 了。官方并没有直接表达不推荐使用，那官方为什么要出这个配置项呢？

1.2 什么是可擦除语法

就在上周，TypeScript 发布了 5.8 版本，其中有一个改动是添加了 --erasableSyntaxOnly 配置选项，开启后仅允许使用可擦除语法，否则会报错。enum 就是一个不可擦除语法，开启 erasableSyntaxOnly 配置后，使用 enum 会报错。

例如，如果在 tsconfig 文件中配置 "erasableSyntaxOnly": true（只允许可擦除语法），此时使用不可擦除语法，将会得到报错：

可擦除语法就是可以直接去掉的、仅在编译时存在、不会生成额外运行时代码的语法，例如 type，interface。不可擦除语法就是不能直接去掉的、需要编译为JS且会生成额外运行时代码的语法，例如 enum，namesapce(with runtime code)。 具体举例如下：

可擦除语法，不生成额外运行时代码，比如 type、let n: number、interface、as number 等：

不可擦除语法，生成额外运行时代码，比如 enum、namespace（具有运行时行为的）、类属性参数构造语法糖（Class Parameter properties）等：

// 枚举类型

enum METHOD {

  ADD = 'add'

}



// 类属性参数构造

class A {

  constructor(public x: number) {}

}

let a: number = 1

console.log(a)

需要注意，具有运行时行为的 namespace 才属于不可擦除语法。

// 不可擦除，具有运行时逻辑

namespace MathUtils {

  export function add(a: number, b: number): number {

    return a + b;

  }

}



// 可擦除，仅用于类型声明，不包含任何运行时逻辑

namespace Shapes {

  export interface Rectangle {

    width: number;

    height: number;

  }

}

1.3 TS 官方为什么要出 erasableSyntaxOnly？

官方既然没有直接表达不推荐 enum，那为什么要出 erasableSyntaxOnly 配置来排除 enum 呢？

我找到了 TS 官方文档（The --erasableSyntaxOnly Option）说明：

大致意思是说之前 Node 新版本中支持了执行 TS 代码的能力，可以直接运行包含可擦除语法的 TypeScript 文件。Node 将用空格替换 TypeScript 语法，并且不执行类型检查。总结下来就是：

在 Node 22 版本：

• 需要配置 --experimental-transform-types 执行支持 TS 文件


• 要禁用 Node 这种特性，使用参数 --no-experimental-strip-types

在 Node 23.6.0 版本：

• 默认支持直接运行可擦除语法的 TS 文件，删除参数 --no-experimental-strip-types


• 对于不可擦除语法，使用参数 --experimental-transform-types

综上所述，TS 官方为了配合 Node.js 这次改动（即默认允许直接执行不可擦除语法的 TS 代码），才添加了一个配置项 erasableSyntaxOnly，只允许可擦除语法。

2. Enum 的三大罪行

自 Enum 从诞生以来，它一直是前端界最具争议的特性之一，许多前端开发者乃至不少大佬都对其颇有微词，纷纷发起了 DO NOT USE TypeScript Enum 的吐槽。那么enum 真的有那么难用吗？我认为是的，这玩意坑还挺多的，甲级战犯 Enum，出列！

2.1 枚举默认值

enum 默认的枚举值从 0 开始，这还不是最关键的，你传入了默认枚举值时，居然是合法的，这无形之中带来了类型安全问题。

enum METHOD {

    ADD

}



function doAction(method: METHOD) {

  // some code

}



doAction(METHOD.ADD) // ✅ 可以

doAction(0) // ✅ 可以

2.2 不支持枚举值字面量

还有一种场景，我要求既可以传入枚举类型，又要求传入枚举值字面量，如下所示，但是他又不合法了？（有人说你定义传枚举类型就要传相应的枚举，这没问题，但是上面提到的问题又是怎么回事呢？这何尝不是 Enum 的双标？）

enum METHOD {

    ADD = 'add'

}



function doAction(method: METHOD) {

  // some code

}



doAction(METHOD.ADD) // ✅ 可以

doAction('add') // ❌ 不行	

2.3 增加运行时开销

TypeScript 的 enum 在编译后会生成额外的 JavaScript 双向映射数据，这会增加运行时的开销。

3. Enum 的替代方案

众所周知，TS 一大特性是类型变换，我们可以通过类型操作组合不同类型来达到目标类型，又称为类型体操。下面的四种解决方案，可以根据实际需求来选择。

3.1 const enum

const enum 是解决产生额外生成的代码和额外的间接成本有效且快捷的方法，但不推荐使用。

const enum 由于编译时内联带来了性能优化，但在 .d.ts 文件、isolatedModules 兼容性、版本不匹配及运行时缺少 .js 文件等场景下存在隐藏陷阱，可能导致难以发现的 bug。详见官方说明：const-enum-pitfalls

const enum METHOD {

  ADD = 'add',

  DELETE = 'delete',

  UPDATE = 'update',

  QUERY = 'query',

}



function doAction(method: METHOD) {

    // some code

}



doAction(METHOD.ADD) // ✅ 可行

doAction('delete') // ❌ 不行

const enum 解析后的代码中引用 enum 的地方将直接被替换为对应的枚举值：

3.2 模板字面量类型

将枚举类型包装为模板字面量类型（Template Literal Types），从而即支持枚举类型，又支持枚举值字面量，但是没有解决运行时开销问题。

enum METHOD {

  ADD = 'add',

  DELETE = 'delete',

  UPDATE = 'update',

  QUERY = 'query',

}



type METHOD_STRING = `${METHOD}`



function doAction(method: METHOD_STRING) {

    // some code

}



doAction(METHOD.ADD) // ✅ 可行

doAction('delete') // ✅ 可行

doAction('remove') // ❌ 不行

3.3 联合类型（Union Types）

使用联合类型，引用时可匹配的值限定为指定的枚举值了，但同时也没有一个地方可以统一维护枚举值，如果一旦枚举值有调整，其他地方都需要改。

type METHOD =

  | 'add'

  /**

   * @deprecated 不再支持删除

   */

  | 'delete'

  | 'update'

  | 'query'





function doAction(method: METHOD) {

    // some code

}



doAction('delete') // ✅ 可行，没有 TSDoc 提示

doAction('remove') // ❌ 不行

3.4 类型字面量 + as const（推荐）

类型字面量就是一个对象，将一个对象断言（Type Assertion）为一个 const，此时这个对象的类型就是对象字面量类型，然后通过类型变换，达到即可以传入枚举值，又可以传入枚举类型的目的。

const METHOD = {

  ADD:'add',

  /**

  * @deprecated 不再支持删除

  */

  DELETE:'delete',

  UPDATE: 'update',

  QUERY: 'query'

} as const



type METHOD_TYPE = typeof METHOD[keyof typeof METHOD]



function doAction(method: METHOD_TYPE) {

  // some code

}



doAction(METHOD.DELETE) // ✅ 可行，有 TSDoc 提示

doAction('delete') // ✅ 可行

doAction('remove') // ❌ 不行

3.5 Class 类静态属性自定义实现

还有一种方法，参考了 @Hamm 提供的方法，即利用 TS 面向对象的特性，自定义实现一个枚举类，实际上这很类似于后端定义枚举的一般方式。这种方式具有很好的扩展性，自定义程度更高。

4. 总结

• TS 可擦除语法 是指 type、interface、n:number 等可以直接去掉的、仅在编译时存在、不会生成额外运行时代码的语法


• TS 不可擦除语法 是指 enum、constructor(public x: number) {} 等不可直接去除且会生成额外运行时代码的语法


• Node.js 23.6.0 版本开始 默认支持直接执行可擦除语法 的 TS 文件


• enum 的替代方案有多种，取决于实际需求。用字面量类型 + as const 是比较常用的一种方案。

TS 官方为了兼容 Node.js 23.6.0 这种可执行 TS 文件特性，出了 erasableSyntaxOnly 配置禁用不可擦除语法，反映了 TypeScript 官方对减少运行时开销和优化编译输出的关注，而不是要放弃 enum。

但或许未来就是要朝着这个方向把 enum 优化掉也说不定呢？

5. 参考链接

• An ode to typescript enums


• TypeScript --erasablesyntaxonly-option


• Node.js type-stripping


• Node.js --experimental-strip-types


• TypeScript const-enums


• TypeScript使用枚举封装和装饰器优雅的定义字典

作者：Shubhransh Rai

Linux 之父把 AI 泡沫喷了个遍

前言： 一篇“技术老炮”的情绪宣泄文而已,说白了，这篇文章就是作者用来发泄不满的牢骚文。全篇围绕一个中心思想打转：我讨厌 AI 炒作，讨厌到牙痒痒。

但话说回来，没炒作怎么能让大众知道、接受这些新技术？大家都讨厌广告，可真到了你要买东西的时候，没有广告你上哪儿去找好产品？炒作虽然惹人烦，但在商业世界里，它就是传播的方式——不然怎么让一个普通人知道什么是AI？

所以归根到底，这篇文章其实并不是在批评 AI 本身，更不是在否定技术的未来。它只是在重复一个观点：**我就是讨厌炒作。**而已。

Linus Torvalds 刚刚狠狠喷了整个 AI 行业 —— 而且他说得没错

Linus Torvalds —— 那个基本上构建出现代计算的人 —— 直接放出了他对 AI 的原话。

他的结论？

“90% 是营销，10% 是现实。”

毒辣。准确。而且，说实话，早该有人站出来讲了。

在维也纳的开源峰会上，Torvalds 对 AI 的炒作问题发表了一番咬牙切齿的评论，他说：

“我觉得 AI 确实很有意思，我也觉得它终将改变世界。但与此同时，我真的太讨厌这类炒作循环了，我真的不想卷进去。”

这个人见过太多科技泡沫的兴起和崩塌。现在？AI 是下一个加密货币。

Torvalds 的应对方式：直接无视

AI 的炒作已经到了让人无法忍受的地步，甚至连 Linus —— 也就是发明了 Linux 的人 —— 都选择闭麦了。

“所以我现在对 AI 的态度基本就是：无视。因为我觉得整个围绕 AI 的科技行业都处在一个非常糟糕的状态。”

说真的？Respect。

我们现在活在一个时代，每个初创公司都在自己网站上贴上“AI 加持”，然后祈祷能拿到风投。

现实呢？这些所谓的“AI 公司”绝大多数不过是把 OpenAI 的 API 包装了一层花哨的 UI。

甚至那些大厂 —— Google、微软、OpenAI —— 也在砸几百亿美元，试图说服大家 AGI（通用人工智能）马上就来了。

与此同时，AI 模型却在数学题上瞎编，还能虚构出不存在的法律案件。

Torvalds 是科技圈为数不多的几个，完全没必要陪大家演戏的人。

他没在卖 AI 产品，也不需要讨好投资人。

他看到 BS（胡扯）就直说。

五年内 AI 的现实检验

Torvalds 也承认，AI 最终会有用的……

“再过五年，情况会变，到时候我们就会看到 AI 真正被用在日常工作负载中了。”

这是目前最靠谱的观点了。

现在的 AI，基本上：

• 写一些烂代码，让真正的工程师收拾残局。

• 吐出一堆 AI 生成垃圾，被 SEO 农场铺满互联网。

• 以前所未有的速度生成公司里的官话废话。

再等五年，我们要么看到实际的生产力提升，要么看到一堆烧光 hype 的 AI 创业公司坟场。

Torvalds 谈 AI 优点：“ChatGPT 还挺酷，我猜吧。”

Torvalds 也不完全是个 AI 悲观论者 —— 他承认确实有些场景是真的有用。

“ChatGPT 演示效果挺好，而且显然已经在很多领域用上了，尤其是像图形设计这类。”

听起来挺合理的。AI 工具有些方面确实还行：

• 帮创意项目生成素材

• 自动化一些无聊流程（比如总结文档）

• 让人以为自己变得更高效了

问题是？AI 的炒作和实际效果严重脱节。

我们听到一些 CEO 说“AI 会取代所有软件工程师”，结果 LLM 连基本逻辑都理不清。

Torvalds 一眼看穿了这些噪音。

他的最终结论？

“但我真的讨厌这个炒作周期。”

结语：Linus Torvalds 是科技界最后的清醒人

Torvalds 不讨厌 AI。

他讨厌的是 AI 的炒作机器。

而他是对的。

每一次科技革命，都是先疯狂承诺一堆，然后现实拍脸：

• 互联网泡沫 —— “互联网一夜之间会取代一切！”

• 加密货币泡沫 —— “去中心化能解决所有问题！”

• AI 泡沫 —— “AGI 马上就来了！”

现实呢？

• 互联网确实改变了一切 —— 但用了 20 年。

• 加密货币确实有用 —— 但 99% 的项目都是骗子。

• AI 也终将有用 —— 但现在，它基本上只是公司演戏用的道具。

Linus Torvalds 很清楚这游戏怎么玩。

他见过科技圈的每一波炒作潮起又落。

他的解决办法？

别听那些噪音。关注真正的技术。等 hype 自动消散。

说真的？这是 2025 年最靠谱的建议了。

AI 的炒作到底是个啥？

AI 就是个 hype 吗？是，也不是。

AI 炒作列车全速前进。

所有人都在卖 “生成式 AI”、“预测式 AI”、“自主智能体 AI”，还有不知道接下来啥新词。

硅谷根本停不下来，逮谁跟谁说 AI 会彻底颠覆一切。

问题是：真会吗？

我们来捋一捋。

AI 炒作周期：一套熟悉的骗局

只要你过去二十年关注过科技趋势，你肯定见过这个套路。

Gartner 给它取了个名字：炒作周期（Hype Cycle），它是这样的：

我们现在在哪？

AI 正脸着地掉进“幻灭低谷”。

为啥？

• 大多数 AI 初创公司不过是 OpenAI API 的壳子

• 各种公司贴“AI 加持”标签就为了拉高股价

• 技术贵、不稳定、而且经常瞎编

基本上，我们正处在“先装出来，后面再补课”的阶段。

AI 已经来了（但和你想的不一样）

很多人以为 AI 是个超级智能体，一夜之间能自动化一切。

现实警告：AI 早就来了，真相却挺无聊的。

它没有掌控公司。

它没有替代程序员。

它在干的事包括：

• 过滤垃圾邮件

• 生成客服脚本

• 推荐广告（只是不那么烂而已）

所以，AI 是有用的。

但远没你风投爹说的那么牛。

预测式 AI vs. 生成式 AI：真正的游戏

AI 可以分两大类：

生成式 AI 吸引了全部目光，因为它光鲜亮丽。

预测式 AI 才是挣钱的正道，因为它解决了真正的商业问题。

比如？

• 医疗：预测疾病暴发

• 金融：在诈骗发生前识别它

• 零售：在厕纸卖光前优化库存

最好的效果来自两者结合：

预测式 AI 预测未来，生成式 AI 自动应对。

这就是 AI 今天真正能发挥作用的地方。

AI 的未来：炒作 vs. 现实

所以，AI 会真的改变世界吗？

会。

但不是明天。

一些靠谱的预测：

✅ AI 会自动化那些烦人的工作 —— 重复性任务直接消失

✅ AI 会提升效率 —— 前提是公司别再吹过头

✅ AI 会无处不在 —— 某些我们根本注意不到的地方

一些纯 BS 的预测：

❌ AI 会替代所有工作 —— 它还是得靠人引导

❌ AGI 马上就来了 —— 不可能，别骗了

❌ AI 是完美且无偏见的 —— 它是喂互联网垃圾长大的

最终结论：AI 既被过度炒作，又是不可避免的未来

AI 是不是 hype？当然是。

AI 会不会消失？绝对不会。

现在大多数 AI 项目，都是营销秀。

但再过 5 到 10 年，最后活下来的赢家会是那些：

• 真正把 AI 用在合适地方的公司

• 关注解决实际问题，而不是追热词的公司

• 不再把 AI 当魔法，而是当工具对待的公司

hype 会死。

有用的东西会留下来。

【新智元导读】谷歌将改变一直以来对 Android 开源项目（AOSP）的公开开发模式，转而在私有环境中进行。但这并非意味着 Android 彻底闭源。对于普通用户而言不会有什么影响，但却让科技爱好者失去了一扇「窥视」安卓内部的窗口。

据 Android Authority 报道，谷歌已经向其确认，谷歌将很快在私有环境中开发 Android 开源项目（AOSP，Android Open Source Project），但依然会开源代码。

网站地址：http://www.android.com/

很多小伙伴可能会慌了，我的安卓手机不能用了？

目前来看，谷歌私下开发 AOSP 项目还不至于到「天塌下来」的地步，普通手机用户更是几乎感觉不到什么变化。

大部分主流手机厂商（比如小米、vivo、三星等）早就跟谷歌签好了各种合作伙伴协议。

只要这些协议还在，厂商们就还能照常拿到最新的 Android 源代码，通过 Google 自家的认证，正常预装 Google Play、Gmail 这些服务和应用。

谷歌对安卓系统的支持也不会断。

一句话，还是老样子。

那么问题来了，谷歌到底做了什么？

这就要从谷歌的安卓开源项目（AOSP）说起了。

什么是 Android Open Source Project（AOSP）？

AOSP 简单来说，就是谷歌给所有 Android 设备提供了一个「毛坯房」——操作系统的基本框架和核心部件。

任何开发者都可以免费下载它的代码，随意改动、分发，然后打造自己的定制系统。

比如小米 HyperOS、vivo OriginOS 都是在 AOSP 基础上搭建起来的。

网站地址：source.android.com/?hl=zh-cn

而 Android 系统本身是跑在 Linux 内核上，这个内核用的是 GPL 许可证，规则挺严格。

简单说就是，只要使用采用了 GPL 许可证的代码，你就得开源，体现「要玩就一起玩」的精神。

但 Google 为了让 Android 既开源又能赚钱，玩了个聪明设计：底层 Linux 内核老实按 GPL 开源，但中间 AOSP 大部分代码却用宽松的 Apache 2.0 许可证。

这样厂商既能自由改动 Android，不用全盘公开，还能加自己专有的东西，既开放又灵活。

具体来说，Linux 内核和模块还得开源，但到了用户空间的应用就不受 GPL 限制，想闭源就闭源。

结果就是，AOSP 底层 GPL 开源，中层 Apache 宽松开源，上层应用随开发者意愿，想怎么玩就怎么玩。

谷歌的这点小聪明那是相当的成功。

回想将近二十年前，智能手机刚起步那会儿，苹果发布了 iPhone。

谷歌也想在移动市场分一杯羹，于是决定推出 Android。

这不光帮助谷歌赚了个技术开放的好名声，还把一大堆厂商和用户从塞班、诺基亚、Windows Mobile、黑莓手里抢了过来。

真是神来之笔。

Android 开源这步棋，绝对是谷歌今天能占据移动操作系统市场七成以上份额的最大功臣。

市场是拿到了，代价是 AOSP 软件的维护是要做的。

问题是，随着手机的功能越来越多，这种维护工作的代价也越来越大。

终于，谷歌忍不了了。

代码同步难，谷歌决定「关起门」来开发，但依然开源代码

写过代码的都知道相比写代码，「合并代码」反而是最令人头疼的问题。

2007 年，谷歌开放了安卓的核心代码，这步棋让谷歌摘取了移动互联网时代最大的果实。

但是也导致安卓这个项目有了两个「主分支」。

一个分支就是公共的 AOSP 分支，这个分支对任何人都开放，大家所说的「安卓是开源」就是指这个分支。

一些附属功能，比如蓝牙功能，仍然在 AOSP 分支中公开开发，你可以在开源的 Android Code Search 中搜索到相关源代码。

然而，AOSP 公共分支并不包含谷歌专有的应用和服务，比如 Google Play 商店、Gmail、Google Maps 等。

AOSP 虽然没有谷歌自己的服务，但是仍然可以编译为一个完整的可用操作系统。

许多设备制造商基于 AOSP 开发自己的操作系统，包括：

• 三星：开发了 One UI。


• 小米：开发了 MIUI。


• OPPO：开发了 ColorOS。


• 华为：开发了早期的 EMUI。


• 一加：开发了 OxygenOS。

另一个分支则是完全的闭源开发，可以看做谷歌自己的安卓「亲儿子」。

这个分支仅限于拥有谷歌移动服务（GMS）许可协议的公司使用，以上类似三星 One UI 这种 Android 系统也可以使用，只要谷歌给予授权。

目前来看，大多数组件，包括核心 Android 操作系统框架，都是在 Google 的内部分支中私下开发的。

两个分支导致一个很大问题，就是内部分支的开发进度领先于公开的 AOSP，导致两个分支差异很大。

这种差异逼得谷歌必须花费时间和精力在公共 AOSP 分支与其内部分支之间合并补丁上。

这就到了程序员「喜闻乐见」的环节，由于分支差异很大，合并冲突经常出现。

以这个启用导航栏和键盘屏幕放大功能的补丁为例，该补丁引入了新的辅助功能设置，该设置被放置在辅助功能设置列表的末尾。

这会导致合并冲突，因为 AOSP 与谷歌内部分支之间的列表长度不同（图中变量 accessibility_magnify_nav_and_ime 设置为 58 和 59 冲突）。

虽然针对此特定问题的修复很简单，但当其他许多 AOSP 补丁集成到谷歌的内部分支时，都会触发类似的合并冲突。

另一个例子是，开发 Android 的新仅解锁存储区域 API 需要一位 Google 工程师从内部分支中挑选一个补丁到 AOSP 以解决合并冲突。

这是因为虽然 API 是在 AOSP 中开发的，但包含新 Android 构建标志的文件是在内部开发的。

因此，必须在内部提交一个更新构建标志文件的补丁，然后应用到 AOSP。

也许这些冲突单独看都不难处理，但是架不住可能会有无数这样「合并冲突」的例子。

「累觉不爱」，也许这就是谷歌放弃当前双管齐下的 Android 开发策略，转而将所有开发工作内部化的原因。

这对我们意味着什么？

这一决策整体来说，并不意味着 Android 正在变成「闭源」。

谷歌只是想把「开发过程」藏起来，依然会继续发布源代码。

最大的区别在于，AOSP 公共分支存在时，对于 Android 爱好者和科技行业记者来说，这是一个能够「窥探」Android 最新动向的窗口。

现在这个「窗口」要被谷歌关上了，这可能会让这些科技极客们感到沮丧，因为这减少了他们对 Google 开发工作的洞察力。

对于开发者，这会让他们更难跟上新的 Android 平台变化，因为他们将无法再跟踪 AOSP 中的变化。

比如外国的一个记者在 AOSP 中发现了某些代码变更，然后提前数月就预测了 Pixel 的网络摄像头功能，他还利用 AOSP 中的线索推断出 Android 16 的提前发布日期。

而对于大多数的我们，甚至包括安卓应用开发者，可以说毫无影响。

事实上，从逻辑的角度上，谷歌大概率就是觉得维护代码的成本过高，不论是从 AOSP 合并到内部版本，还是将内部版本的更新带给 AOSP 公共分支，这些工作都需要工程师完成。

可以说这些处理冲突的工作过于「低端」，对于谷歌的工程师来说，耗时耗力而且毫无意义。

但是 AOSP 某种意义上已经可以看做是谷歌在开源生态和程序员心目中的「投名状」。

作为以「不作恶」为公司理念的谷歌，安卓开源这步棋被认为是谷歌最成功的一次战略决策之一。

在极客们看来，这次决策类似于谷歌自己推倒了过去十几年树立起来的「精神丰碑」。

当然，从谷歌自己的角度看来，选择将工作整合在一个内部分支下，同时简化操作系统开发和源代码发布，是可以理解的。

毕竟 AOSP 对 Google 的商业价值，跟当年比起来，已经完全不是一个量级了。

从最近谷歌对 Gemini 以及 Gemma 的疯狂更新来看，AI 才是其工作的重点。

其实所有人都知道，相比于 Gemini，安卓对于谷歌已不再那么重要。

参考资料：

arstechnica.com/gadgets/202…

http://www.androidauthority.com/google-andr…

在 MySQL 中，使用 UUID 作为主键 在大表中可能会导致性能问题，尤其是在插入和修改数据时效率较低。以下是详细的原因分析，以及为什么修改数据会导致索引刷新，以及字符主键为什么效率较低。

1. UUID 作为主键的问题

（1）UUID 的特性

• UUID 是一个 128 位的字符串，通常表示为 36 个字符（例如：550e8400-e29b-41d4-a716-446655440000）。


• UUID 是全局唯一的，适合分布式系统中生成唯一标识。

（2）UUID 作为主键的缺点

1. 索引效率低

• 索引大小：UUID 是字符串类型，占用空间较大（36 字节），而整型主键（如 BIGINT）仅占用 8 字节。索引越大，存储和查询的效率越低。


• 索引分裂：UUID 是无序的，插入新数据时，可能会导致索引树频繁分裂和重新平衡，影响性能。

2. 插入性能差

• 随机性：UUID 是无序的，每次插入新数据时，新记录可能会插入到索引树的任意位置，导致索引树频繁调整。


• 页分裂：InnoDB 存储引擎使用 B+ 树作为索引结构，随机插入会导致页分裂，增加磁盘 I/O 操作。

3. 查询性能差

• 比较效率低：字符串比较比整型比较慢，尤其是在大表中，查询性能会显著下降。


• 索引扫描范围大：UUID 索引占用的空间大，导致索引扫描的范围更大，查询效率降低。

2. 修改数据导致索引刷新的原因

（1）索引的作用

• 索引是为了加速查询而创建的数据结构（如 B+ 树）。


• 当数据被修改时，索引也需要同步更新，以保持数据的一致性。

（2）修改数据对索引的影响

• 更新主键：
  
  
  
  
  • 如果修改了主键值，MySQL 需要删除旧的主键索引记录，并插入新的主键索引记录。
  
  
  • 这个过程会导致索引树的调整，增加磁盘 I/O 操作。
  
  
  
  


• 更新非主键列：
  
  
  
  
  • 如果修改的列是索引列（如唯一索引、普通索引），MySQL 需要更新对应的索引记录。
  
  
  • 这个过程也会导致索引树的调整。
  
  
  
  

（3）UUID 主键的额外开销

• 由于 UUID 是无序的，修改主键值时，新值可能会插入到索引树的不同位置，导致索引树频繁调整。


• 相比于有序的主键（如自增 ID），UUID 主键的修改操作代价更高。

3. 字符主键导致效率降低的原因

（1）存储空间大

• 字符主键（如 UUID）占用的存储空间比整型主键大。


• 索引的大小直接影响查询性能，索引越大，查询时需要的磁盘 I/O 操作越多。

（2）比较效率低

• 字符串比较比整型比较慢，尤其是在大表中，查询性能会显著下降。


• 例如，WHERE id = '550e8400-e29b-41d4-a716-446655440000' 的效率低于 WHERE id = 12345。

（3）索引分裂

• 字符主键通常是无序的，插入新数据时，可能会导致索引树频繁分裂和重新平衡，影响性能。

4. 如何优化 UUID 主键的性能

（1）使用有序 UUID

• 使用有序 UUID（如 UUIDv7），减少索引分裂和页分裂。


• 有序 UUID 的生成方式可以基于时间戳，保证插入顺序。

（2）将 UUID 存储为二进制

• 将 UUID 存储为 BINARY(16) 而不是 CHAR(36)，减少存储空间。
  
  

  CREATE TABLE users (
  
      id BINARY(16) PRIMARY KEY,
  
      name VARCHAR(255)
  
  );
  
  

  
  

（3）使用自增主键 + UUID

• 使用自增主键作为物理主键，UUID 作为逻辑主键。
  
  

  CREATE TABLE users (
  
      id BIGINT AUTO_INCREMENT PRIMARY KEY,
  
      uuid CHAR(36) UNIQUE,
  
      name VARCHAR(255)
  
  );
  
  

  
  

（4）分区表

• 对大表进行分区，减少单个索引树的大小，提高查询性能。

~Summary

• UUID 作为主键的缺点：
  
  
  
  
  • 索引效率低，插入和查询性能差。
  
  
  • 修改数据时，索引需要频繁刷新，导致性能下降。
  
  
  
  


• 字符主键效率低的原因：
  
  
  
  
  • 存储空间大，比较效率低，索引分裂频繁。
  
  
  
  


• 优化建议：
  
  
  
  
  • 使用有序 UUID 或二进制存储。
  
  
  • 结合自增主键和 UUID。
  
  
  • 对大表进行分区。