今天咱们聊个啥呢？先设想一个场景：你辛辛苦苦开发了一个前端应用，后端 API 也写得杠杠的。用户通过你的前端界面提交一个订单，比如说买1件商品。请求发出去，一切正常。但如果这时候，有个“不开眼”的黑客老哥，在你的请求发出后、到达服务器前，悄咪咪地把“1件”改成了“100件”，或者把你用户的优惠券给薅走了，那服务器收到的就是个被篡改过的“假”请求。更狠一点，如果他拿到了你某个用户的合法请求，然后疯狂重放这个请求，那服务器不就炸了？

是不是想想都后怕？别慌，今天咱就来聊聊怎么给咱们的API请求加一把“锁”，让这种“中间人攻击”和“重放攻击”无处遁形。这把锁，就是大名鼎鼎的 HMAC-SHA256 请求签名。学会了它，你就能给你的应用穿上“防弹衣”！

一、光有 HTTPS 还不够？为啥还要请求签名？

可能有机灵的小伙伴会问：“老张，咱不都有 HTTPS 了吗？数据都加密了，还怕啥？”

问得好！HTTPS 确实牛，它能保证你的数据在传输过程中不被窃听和篡改，就像给数据修了条“加密隧道”。但它主要解决的是传输层的安全。可如果：

请求签名，则是在应用层做的一道防线。它能确保：

• 消息的完整性：数据没被篡改过。


• 消息的身份验证：确认消息确实是你授权的客户端发来的。


• 防止重放攻击：结合时间戳或 Nonce，让每个请求都具有唯一性。

它和 HTTPS 是好搭档，一个负责“隧道安全”，一个负责“货物安检”，双保险！

二、主角登场：HMAC-SHA256 是个啥？

HMAC-SHA256，听起来挺唬人，拆开看其实很简单：

• HMAC：Hash-based Message Authentication Code，翻译过来就是“基于哈希的消息认证码”。它是一种使用密钥（secret key）来生成消息摘要（MAC）的方法。


• SHA256：Secure Hash Algorithm 256-bit，一种安全的哈希算法，能把任意长度的数据转换成一个固定长度（256位，通常表示为64个十六进制字符）的唯一字符串。相同的输入永远得到相同的输出，输入有任何微小变化，输出都会面目全非。

所以，HMAC-SHA256 就是用一个共享密钥 (Secret Key)，通过 SHA256 算法，给你的请求数据生成一个独一无二的“签名”。

三、签名的艺术：请求是怎么被“签”上和“验”货的？

整个流程其实不复杂，咱们用个图来说明一下：

sequenceDiagram

    participant C as 前端 (Client)

    participant S as 后端 (Server)



    C->>C: 1. 准备请求参数 (如 method, path, query, body)

    C->>C: 2. 加入时间戳 (timestamp) 和/或 随机数 (nonce)

    C->>C: 3. 将参数按约定规则排序、拼接成一个字符串 (stringToSign)

    C->>C: 4. 使用共享密钥 (Secret Key) 对 stringToSign 进行 HMAC-SHA256 运算，生成签名 (signature)

    C->>S: 5. 将原始请求参数 + timestamp + nonce + signature 一起发送给后端



    S->>S: 6. 接收到所有数据

    S->>S: 7. 校验 timestamp/nonce (检查是否过期或已使用，防重放)

    S->>S: 8. 从接收到的数据中，按与客户端相同的规则，提取参数、排序、拼接成 stringToSign'

    S->>S: 9. 使用自己保存的、与客户端相同的 Secret Key，对 stringToSign' 进行 HMAC-SHA256 运算，生成 signature'

    S->>S: 10. 比对客户端传来的 signature 和自己生成的 signature'

    alt 签名一致

        S->>S: 11. 验证通过，处理业务逻辑

        S-->>C: 响应结果

    else 签名不一致

        S->>S: 11. 验证失败，拒绝请求

        S-->>C: 错误信息 (如 401 Unauthorized)

    end

简单来说，就是：

四、Talk is Cheap, Show Me The Code!

光说不练假把式，咱们来点实在的。

前端签名 (JavaScript - 通常使用 crypto-js 库)

// 假设你已经安装了 crypto-js: npm install crypto-js

import CryptoJS from 'crypto-js';



function generateSignature(params, secretKey) {

  // 1. 准备待签名数据

  const method = 'GET'; // 请求方法

  const path = '/api/user/profile'; // 请求路径

  const timestamp = Math.floor(Date.now() / 1000).toString(); // 时间戳 (秒)

  const nonce = CryptoJS.lib.WordArray.random(16).toString(); // 随机数，可选



  // 2. 构造待签名字符串 (规则很重要，前后端要一致！)

  // 通常会对参数名按字典序排序

  const sortedKeys = Object.keys(params).sort();

  const queryString = sortedKeys.map(key => `${key}=${params[key]}`).join('&');



  const stringToSign = `${method}\n${path}\n${queryString}\n${timestamp}\n${nonce}`;

  console.log("String to Sign:", stringToSign); // 调试用



  // 3. 使用 HMAC-SHA256 生成签名

  const signature = CryptoJS.HmacSHA256(stringToSign, secretKey).toString(CryptoJS.enc.Hex);

  console.log("Generated Signature:", signature); // 调试用



  return {

    signature,

    timestamp,

    nonce

  };

}



// --- 使用示例 ---

const mySecretKey = "your-super-secret-key-dont-put-in-frontend-directly!"; // 强调：密钥不能硬编码在前端！

const requestParams = {

  userId: '123',

  role: 'user'

};



const { signature, timestamp, nonce } = generateSignature(requestParams, mySecretKey);



// 实际发送请求时，把 signature, timestamp, nonce 放在请求头或请求体里

// 例如：

// fetch(`${path}?${queryString}`, {

//   method: method,

//   headers: {

//     'X-Signature': signature,

//     'X-Timestamp': timestamp,

//     'X-Nonce': nonce,

//     'Content-Type': 'application/json'

//   },

//   // body: JSON.stringify(requestBody) // 如果是POST/PUT等

// })

// .then(...)

划重点！ 上面代码里的 mySecretKey 绝对不能像这样直接写在前端代码里！这只是个演示。真正的 Secret Key 需要通过安全的方式分发和存储，比如在构建时注入，或者通过更安全的认证流程动态获取（但这又引入了新的复杂性，通常 Secret Key 是后端持有，客户端动态获取一个有时效性的 token）。对于纯前端应用，更常见的做法是后端生成签名所需参数，或者整个流程由 BFF (Backend For Frontend) 层处理。如果你的应用是 App，可以把 Secret Key 存储在原生代码中，相对安全一些。

后端验签 (Node.js - 使用内置 crypto 模块)

const crypto = require('crypto');



function verifySignature(requestData, clientSignature, clientTimestamp, clientNonce, secretKey) {

  // 0. 校验时间戳 (例如，请求必须在5分钟内到达)

  const serverTimestamp = Math.floor(Date.now() / 1000);

  if (Math.abs(serverTimestamp - parseInt(clientTimestamp, 10)) > 300) { // 5分钟窗口

    console.error("Timestamp validation failed");

    return false;

  }



  // (可选) 校验 Nonce 防止重放，需要存储已用过的 Nonce，可以用 Redis 等

  // if (isNonceUsed(clientNonce)) {

  //   console.error("Nonce replay detected");

  //   return false;

  // }

  // markNonceAsUsed(clientNonce, clientTimestamp); // 标记为已用，并设置过期时间



  // 1. 从请求中提取参与签名的参数

  const { method, path, queryParams } = requestData; // 假设已解析好



  // 2. 构造待签名字符串 (规则必须和客户端完全一致！)

  const sortedKeys = Object.keys(queryParams).sort();

  const queryString = sortedKeys.map(key => `${key}=${queryParams[key]}`).join('&');



  const stringToSign = `${method}\n${path}\n${queryString}\n${clientTimestamp}\n${clientNonce}`;

  console.log("Server String to Sign:", stringToSign);



  // 3. 使用 HMAC-SHA256 生成签名

  const expectedSignature = crypto.createHmac('sha256', secretKey)

                               .update(stringToSign)

                               .digest('hex');

  console.log("Server Expected Signature:", expectedSignature);

  console.log("Client Signature:", clientSignature);



  // 4. 比对签名 (使用 crypto.timingSafeEqual 防止时序攻击)

  if (clientSignature.length !== expectedSignature.length) {

    return false;

  }

  return crypto.timingSafeEqual(Buffer.from(clientSignature), Buffer.from(expectedSignature));

}



// --- Express 示例中间件 ---

// app.use((req, res, next) => {

//   const clientSignature = req.headers['x-signature'];

//   const clientTimestamp = req.headers['x-timestamp'];

//   const clientNonce = req.headers['x-nonce'];

//   // 实际项目中，secretKey 应该从环境变量或配置中读取

//   const API_SECRET_KEY = process.env.API_SECRET_KEY || "your-super-secret-key-dont-put-in-frontend-directly!";



//   // 构造 requestData 对象，包含 method, path, queryParams

//   // 注意：如果是 POST/PUT 请求，请求体 (body) 通常也需要参与签名

//   // 且 body 如果是 JSON，建议序列化后参与签名，而不是原始对象

//   const requestDataForSig = {

//     method: req.method.toUpperCase(),

//     path: req.path,

//     queryParams: req.query, // 对于GET；POST/PUT可能还需包含body

//     // bodyString: req.body ? JSON.stringify(req.body) : "" // 如果body参与签名

//   };



//   if (!verifySignature(requestDataForSig, clientSignature, clientTimestamp, clientNonce, API_SECRET_KEY)) {

//     return res.status(401).send('Invalid Signature');

//   }

//   next();

// });

五、细节是魔鬼：实施过程中的注意事项

六、HMAC-SHA256 vs. 其他方案？

HMAC-SHA256 更侧重于请求本身的完整性和来源认证，而 JWT 更侧重于用户身份的认证和授权。它们可以结合使用。

好啦，今天关于 HMAC-SHA256 请求签名的唠嗑就到这里。这玩意儿看起来步骤多，但一旦理解了原理，实现起来其实就是细心活儿。给你的 API 加上这把锁，晚上睡觉都能踏实点！

我是老码小张，一个喜欢研究技术原理，并且在实践中不断成长的技术人。希望今天的分享对你有帮助，咱们下回再聊！欢迎大家留言交流你的看法和经验哦！

这篇文章，我们聊聊 四种实时通信技术：短轮询、长轮询、WebSocket 和 SSE 。

1 短轮询

浏览器 定时（如每秒）向服务器发送 HTTP 请求，服务器立即返回当前数据（无论是否有更新）。

• 优点：实现简单，兼容性极佳


• 缺点：高频请求浪费资源，实时性差（依赖轮询间隔）


• 延迟：高（取决于轮询频率）


• 适用场景：兼容性要求高，延迟不敏感的简单场景。

笔者职业生涯印象最深刻的短轮询应用场景是比分直播：

如图所示，用户进入比分直播界面，浏览器定时查询赛事信息（比分变动、黄红牌等），假如数据有变化，则重新渲染页面。

这种方式实现起来非常简单可靠，但是频繁的调用后端接口，会对后端性能会有影响（主要是 CPU）。同时，因为依赖轮询间隔，页面数据变化有延迟，用户体验并不算太好。

2 长轮询

浏览器发送 HTTP 请求后，服务器 挂起连接 直到数据更新或超时，返回响应后浏览器立即发起新请求。

• 优点：减少无效请求，比短轮询实时性更好


• 缺点：服务器需维护挂起连接，高并发时资源消耗大


• 延迟：中（取决于数据更新频率）


• 适用场景：需要较好实时性且无法用 WebSocket/SSE 的场景（如消息通知）

长轮询最常见的应用场景是：配置中心，我们耳熟能详的注册中心 Nacos 、阿波罗都是依赖长轮询机制。

客户端发起请求后，Nacos 服务端不会立即返回请求结果，而是将请求挂起等待一段时间，如果此段时间内服务端数据变更，立即响应客户端请求，若是一直无变化则等到指定的超时时间后响应请求，客户端重新发起长链接。

3 WebSocket

基于 TCP 的全双工协议，通过 HTTP 升级握手（Upgrade: websocket）建立持久连接，双向实时通信。

• 优点：最低延迟，支持双向交互，节省带宽


• 缺点：实现复杂，需单独处理连接状态


• 延迟：极低


• 适用场景：聊天室、在线游戏、协同编辑等 高实时双向交互 需求

笔者曾经服务于北京一家电商公司，参与直播答题功能的研发。

直播答题整体架构见下图：

Netty TCP 网关的技术选型是：Netty、ProtoBuf、WebSocket ，选择 WebSocket 是因为它支持双向实时通信，同时 Netty 内置了 WebSocket 实现类，工程实现起来相对简单。

4 Server Send Event(SSE)

基于 HTTP 协议，服务器可 主动推送 数据流（如Content-Type: text/event-stream），浏览器通过EventSource API 监听。

• 优点：原生支持断线重连，轻量级（HTTP协议）


• 缺点：不支持浏览器向服务器发送数据


• 延迟：低（服务器可即时推送）


• 适用场景：股票行情、实时日志等 服务器单向推送 需求。

SSE 最经典的应用场景是 ： DeepSeek web 聊天界面 ，如图所示：

当在 DeepSeek 对话框发送消息后，浏览器会发送一个 HTTP 请求 ，服务端会通过 SSE 方式将数据返回到浏览器。

5 总结

选择建议：

• 需要 简单兼容性 → 短轮询


• 需要 中等实时性 → 长轮询


• 只需 服务器推送 → SSE


• 需要 全双工实时交互 → WebSocket

引言

📌 Git 是现代开发中不可或缺的版本控制工具，尤其适用于团队协作和代码管理。本文将带你了解 Git 的基础操作命令，包括 git init、git add、git commit、git diff、git log、.gitignore 等，快速上手版本控制。

🛠️ 一、初始化仓库：git init

使用 Git 前，需先初始化一个本地仓库：

git init

执行后会在当前目录生成一个 .git 文件夹，Git 会在此目录下跟踪项目的变更记录。

👤 二、配置用户信息

首次使用 Git 时，推荐设置用户名和邮箱：

git config --global user.name "xxxxx"

git config --global user.email "xxxx@qq.com"

加上 --global 会全局生效，仅对当前项目配置可以省略该参数。

📦 三、代码暂存区（Staging Area）是什么？

Git 的提交操作分为两个阶段：暂存（staging） 和 提交（commit） 。

• 当你修改了文件，Git 并不会立即记录这些改动；


• 你需要先使用 git add 命令，把改动“放进暂存区”，告诉 Git：“这些改动我准备好了，可以提交”；


• 然后再使用 git commit 将暂存区的内容提交到本地仓库，记录为一个快照。

🧠 可以把暂存区类比为“快照准备区”，你可以反复修改文件、添加到暂存区，最后一口气提交，确保每次提交都是有意义的逻辑单元。

🎯 举个例子：

# 修改了 index.html 和 style.css

git add index.html      # 把 index.html 放入暂存区

git add style.css       # 再把 style.css 放入暂存区

git commit -m "更新首页结构和样式"  # 一起提交

💡 小贴士：你可以分批使用 git add 管理暂存内容，按逻辑分组提交更利于协作和回溯。

📝 四、查看当前状态：git status

在进行任何修改之前，查看当前仓库的状态是非常重要的。git status 是最常用的命令之一，能让你清楚了解哪些文件被修改了，哪些文件已加入暂存区，哪些文件未被跟踪。

git status

它的输出通常会分为三部分：

例如：

On branch main

Changes to be committed:

  (use "git reset HEAD <file>..." to unstage)

        modified:   index.html

        new file:   style.css



Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git restore <file>..." to discard changes in working directory)

        modified:   app.js

🎯 通过 git status，你可以随时了解当前工作区和暂存区的状态，帮助你决定接下来的操作。

📥 五、添加文件到暂存区：git add

当你修改或新增文件后，使用 git add 将其添加到 Git 的暂存区：

git add 文件名

也可以批量添加所有修改：

git add .

💾 六、提交更改：git commit -m

将暂存区的内容提交至本地仓库：

git commit -m "提交说明"

-m 后面是提交信息，建议语义清晰，例如：

git commit -m "新增用户登录功能"

🚀 七、推送到远程仓库：git push origin main

本地提交之后，需要推送代码到远程仓库（如 GitHub、Gitee）：

git push origin main

• origin 是默认的远程仓库别名；


• main 是目标分支名（如果你使用的是 master，请替换）；

✅ 提交后远程成员就可以拉取（pull）你最新的修改了。

🔗 如果你还没有远程仓库，请先去 GitHub / Gitee 创建一个，然后关联远程仓库地址：

git remote add origin https://github.com/yourname/your-repo.git

🕵️ 八、查看文件改动：git diff

在 commit 之前，可用 git diff 查看修改内容：

git diff

📜 九、查看提交历史：git log --oneline

快速查看历史提交记录：

git log --oneline

输出示例：

e3f1a1b 添加登录功能

2c3d9a7 初始提交

🛑 十、忽略某些文件：.gitignore

在项目中，有些文件无需提交到 Git 仓库，例如缓存、编译结果、配置文件等。使用 .gitignore 文件可忽略这些文件：

# 忽略 node_modules 文件夹

node_modules/



# 忽略所有 .log 文件

*.log



# 忽略 .env 环境变量文件

.env

🌿 十一、重命名默认分支：git branch -M main

很多平台（如 GitHub）推荐使用 main 作为主分支名称：

git branch -M main

这样可以将默认分支由 master 改为 main。

✅ 总结命令一览表

🧠 写在最后

Git 是每个开发者都必须掌握的技能之一。掌握好这些常用命令，就能覆盖 90% 的使用场景。未来如果你要进行多人协作、分支合并、冲突解决，这些基础就是你的武器库。

觉得实用就点个赞、关注、收藏支持一下吧 🙌

前言

从我最开始用 Cursor 到现在已经有几个月了，然而随着对它的使用时间越来越长，我感觉帮助反而慢慢变小了，一度我这个月想着不续费了，然后我以为 13 到期、结果却是 7 号到期，所以又自动续费了。

最开始接触

我已经用了 Cursor 好几个月了，而我最开始用 Cursor 是在好几个月前。

最开始在社交平台上了解到它的功能后，我就很激动了，感觉这也太神了，就一直想体验。但那时也了解到它的价格的何等的贵，所以我开始并没有直接去下载它，而是找了平替 Windsurf

但别说用了，连注册都注册不了，反复试了几天，也没有注册成功。换手机、换科学上网的不同提供商，都没用。这不，才开始用 Cursor。

无限续杯 之 走到终点

等我用了之后，体验了它的14天免费时间。之后我就觉得它太强了。很多我可以写的功能，它可以以更好的方式，很快的方式生成出来。然而很多我还不会写的。它依然可以去实现。但14天很快就过去了，接着就是一段时间 帐号的删除与注册。但好景不长...

终于在多次反复删除账号又注册。这种操作对我来说已经失效了。

看过了掘金的大多教程，都没有什么用，最后一次有用，但第二天就又不行了。

但那段时间刚巧，我之前在找工作，那几天刚好入职。我就在工作中用了它，有意思的是，我们公司并没有人知道 cursor，甚至没人知道有 ai编辑器。过了几天，无限续杯 也刚好达到极限。

充会员 -> 早下班

当我体验了 Cursor 的威力后，我已经要离不开它了。

我是前端，而 Cursor 可以支持发给它图片，让它画页面。其实画的还挺不错的，这一点就深得我心，所以我痛定思痛充了会员。

那段时间，我就没加过班、自在的我自己都不知道该如何描述了。但刚开始还是不怎么舒服，因为它老是给我生成用 element-plus 组件直接写的，而我们公司有不少组件是二次封装的，导致我总是要改它。但用了十几次后，它就知道我要什么了。

用了哪些功能 与 自己的感受

Tab 的好与不好

我常用的功能就是tab，主要的是它比较灵活，生成的速度也比较快。而且用的越多它就越可以生成想要的代码。比如项目中自己封装的组件。用 tab 几次之后，它就自己可以去用这个组件，但更多情况下，它生成的会是之前写过的内容。

不过它也有一些缺点，比如：不能去预判一些复杂的思路。如果我们写了一个按钮，并在按钮身上绑定一个 Click 事件，名称叫做 search。Cursor 的 Tab 就可以自动会生成 search函数。但如果你只是在这里写了一个按钮，想要做的功能是导出。你没有在按钮上写导出两个字，也没有去绑定一个 Click事件 叫 export。那 Cursor 根本就不知道你要做的是导出，也就不会去自动实现这些功能。

另一个 Tab 的缺点，那就是影响复制功能。经常准备复制内容时，Tab 就给出了它的预判，然而原本你打算复制10个字，此时它的预判在 10个字中间加了 30个字。你要是想复制，正常就会用鼠标选中字，可一旦你鼠标点下那个位置，Tab就来了。我多次遇到这个问题，如果你没有遇到过，请教我一下方法。

对话模式

对话分两种，一种是全局，一种是局部。

先来说一下全局。

全局对话 cmd + i

由于 Cursor 默认会将所有文件自动追踪索引。所以当我们进行全局对话时， Cursor 会基于全局所有文件的索引为基础。去修改现在的代码，但如果我们只想改当前一个页面，它依然会去分析全局，增加了要处理的数据量，就导致时间比较长。

不知道是不是我的科学上网工具问题，我几乎只要用全局问答，就要好几分钟，要是改错了，又要重来，所以现在几乎就不用了。

另一个是后面代码变多了，时间就更长，而且它老是给我优化我不要优化的，因为它经常优化错了。比如关于接口的 type，我都是在 api 文件夹中定义的。但它总说在那个文件中没有这个 type，然后就自动在当前文件附近又创建 types.ts ，然后声明的类型和接口都不是对应的。

当然了，它的好处是分析的全面、如果要跨多个文件修改同一个功能，则它再慢，也得等着。

之后我就又想起了 局部 对话

局部对话 cmd + k

我是上段时间才开始用这个的，因为全局的太慢了，就突然想起来还有局部的 cmd ➕ k 。这个还不错，我最初是用来写 API 数据的。

因为我们是用 ApiPost，我就直接在左边接口标题处，点击复制，然后进代码，在局部问答中发给他，然后说，写出接口和类型。基本没出过错。

用了几天后也发现它的局限性了，就是它貌似只能在问的位置下方生成，如果我要它跨越几个地方添加就没用了。如：在template中生成页面展示的，在JS中生成脚本，在style中生成样式。

但之后发现这种方式不仅能生成，如果你选中了内容，它还能修改。然后我就随机一动，直接全选当前文件，则实现了对一整个文件的局部修改。但说实话，速度也并没有太快。

cursorrules

后来我又加了cursorrules，最初我以为只能用一个rules文件，直到在一个微信群里看见别人分享的照片，他有6个左右的rules。之后我就用了两天时间自己写了4个rules。但经常没有效果，而且还开启了always。

之后，我就在开始的位置写上这样这句话：

自动激活

这些指令在本项目的所有对话中自动生效。当使用到该 rules 时，要打印出这个rules的名字，如"使用了 项目规则.mdc 文件"，让我知道你使用了这个文件。

之后有一次就突然出现了这句话

可是，只出现过这个 项目规则.mdc ，其它的mdc 都没有出现过，但其它的文件中 我也写了类型的 自动激活的话。不知道为什么没有生效。

MCP

server-sequential-thinking

MCP 之前使用过，那时主要火的是 server-sequential-thinking, 它的主要功能是思维更有条理。如果你在对话中 说了类似 " 思考 " 的话，那就会激活它。之后它就一句话一句话的分析，也一句一句的解释。因为工作中比较少的有这么有深度的思考，我几乎没用过它。而且用了它之后，话也变多了，导致效率也慢，外加 科学上网 的工具并不好，就更慢了。 上段时间我又开始使用它了，但一直没生效，不知道为啥？

playwright 自动化测试

用这个可能比较复杂，其实我就是希望 Cursor 可以自己调接口，然后根据 api 文件中的 对接口的声明、参数类型与返回类型。自动帮我实现 增删改查 ，如果一个表单，我的字段写错了，它就自动修改，然后继续填写数据再调接口。直到跑通为止。 因为这确实很费时间，也没意思。但至今也没有做到。

browser-tool-mcp

这个是用来让 Cursor 监控浏览器，它可以查看浏览器的 控制台、DOM 结构 等等，但用了一段时间后，发现直接把 控制台的报错 发给 Cursor 更快，也就没怎么用了。

结语

上面 MCP 用的不怎么好的一个原因，是因为没有打通 自动化的流程，所以总是需要我手动的操作。

这个星期打算把 claude 的提示词看一下，看看能不能改善一下 Cursor 的使用情况。

还在为无法发送短信验证码而烦恼？今天分享一个超实用的解决方案，个人开发者也能用！

最近国内很多平台暂停了针对个人用户的短信发送，这给个人开发者带来了不少困扰。不过别担心，我发现了一个超实用的解决方案——Spug推送平台，它能很好地满足我们发送短信等需求。

为什么选择这个方案？

三步搞定短信发送

第一步：注册账户

打开push.spug.cc，使用微信扫码直接登录，无需繁琐的认证流程。

第二步：创建模板

第三步：发送短信

复制模版ID，通过API调用即可发送短信。

发送短信验证码代码示例（多种语言）

Python版（推荐）

import requests



def send_sms(template_id, code, phone):

    url = f"https://push.spug.cc/send/{template_id}"

    params = {

        "code": code,

        "targets": phone

    }

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

    return response.json()



# 使用示例

result = send_sms("abc", "6677", "151xxxx0875")

print(result)

Go版

package main



import (

    "fmt"

    "net/http"

    "io/ioutil"

)



func sendSMS(templateID, code, phone string) (string, error) {

    url := fmt.Sprintf("https://push.spug.cc/send/%s?code=%s&targets=%s", 

        templateID, code, phone)

    

    resp, err := http.Get(url)

    if err != nil {

        return "", err

    }

    defer resp.Body.Close()

    

    body, err := ioutil.ReadAll(resp.Body)

    if err != nil {

        return "", err

    }

    

    return string(body), nil

}



func main() {

    result, err := sendSMS("abc", "6677", "151xxxx0875")

    if err != nil {

        fmt.Println("Error:", err)

        return

    }

    fmt.Println(result)

}

Java版

import java.net.HttpURLConnection;

import java.net.URL;

import java.io.BufferedReader;

import java.io.InputStreamReader;



public class SMSSender {

    public static String sendSMS(String templateId, String code, String phone) throws Exception {

        String url = String.format("https://push.spug.cc/send/%s?code=%s&targets=%s",

            templateId, code, phone);

        

        URL obj = new URL(url);

        HttpURLConnection con = (HttpURLConnection) obj.openConnection();

        con.setRequestMethod("GET");

        

        BufferedReader in = new BufferedReader(new InputStreamReader(con.getInputStream()));

        String inputLine;

        StringBuilder response = new StringBuilder();

        

        while ((inputLine = in.readLine()) != null) {

            response.append(inputLine);

        }

        in.close();

        

        return response.toString();

    }



    public static void main(String[] args) {

        try {

            String result = sendSMS("abc", "6677", "151xxxx0875");

            System.out.println(result);

        } catch (Exception e) {

            e.printStackTrace();

        }

    }

}

使用技巧

抓包工具使用指南

序章

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

1. Fiddler 抓包简介

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

1.1 字段说明

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

1.2 Statistics 请求性能数据分析

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

1.3 Inspectors 查看数据内容

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

1.4 AutoResponder 拦截指定请求

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

1.5 Composer 自定义请求发送

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

1.6 Filters 请求过滤规则

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

1.7 Timeline 请求响应时间

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

2. Fiddler 设置解密 HTTPS 数据

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

3. 抓取移动端数据包

3.1 设置代理

3.2 安装证书

3.3 抓取数据包

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

4. Fiddler 内置命令与断点

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

断点功能

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

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


• bpu：中断响应。


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


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

5. SniffMaster 抓包大师

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

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


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


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


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

5.1 SniffMaster 使用场景

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


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


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

总结

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

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

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

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

1. 代码会被分享和同步

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

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

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

3. 环境迁移的噩梦

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

正确的做法

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

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


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


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


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

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

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

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

提醒一下

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

token有效期设置问题

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

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

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

双token无感刷新方案

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

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

核心设计

大致的执行流程如下

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

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

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

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

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

@Service

public class LoginServiceImpl implements LoginService {



    @Autowired

    private JwtUtils jwtUtils;



    // token过期时间

    private static final Integer TOKEN_EXPIRE_DAYS =5;

    // token续期时间



    private static final Integer TOKEN_RENEWAL_MINUTE =15;



    @Override

    public boolean verify(String refresh_token) {

        Long uid = jwtUtils.getUidOrNull(refresh_token);

        if (Objects.isNull(uid)) {

            return false;

        }

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

        String realToken = RedisUtils.getStr(key);

        return Objects.equals(refresh_token, realToken);

    }



    @Override

    public void renewalTokenIfNecessary(String refresh_token) {

        Long uid = jwtUtils.getUidOrNull(refresh_token);

        if (Objects.isNull(uid)) {

            return;

        }

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

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

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

            return;

        }

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

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

    }



    @Override

    @Transactional(rollbackFor = Exception.class)

    @RedissonLock(key = "#uid")

    public LoginTokenResponse login(Long uid) {

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

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

        String refresh_token = RedisUtils.getStr(refresh_key);

        String access_token;

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

            access_token = jwtUtils.createToken(uid);

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

            return LoginTokenResponse.builder()

                    .refresh_token(refresh_token).access_token(access_token)

                    .build();

        }

        refresh_token = jwtUtils.createToken(uid);

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

        access_token = jwtUtils.createToken(uid);

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

        return LoginTokenResponse.builder()

                .refresh_token(refresh_token).access_token(access_token)

                .build();

    }

}}

注意事项

安全问题

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

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

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

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

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

大家好呀，我是猿java。

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

1. 什么是灰度发布？

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

2. 原理解析

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

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

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


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


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

3. 示例演示

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

3.1 第一步：引入灰度策略

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

import org.springframework.stereotype.Component;

import org.springframework.web.servlet.HandlerInterceptor;



import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.util.Random;



@Component

public class GrayReleaseInterceptor implements HandlerInterceptor {



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



    @Override

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

        String uri = request.getRequestURI();

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

            if (isGrayRelease()) {

                // 重定向到新版本接口

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

                return false;

            } else {

                // 使用旧版本接口

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

                return false;

            }

        }

        return true;

    }



    private boolean isGrayRelease() {

        Random random = new Random();

        return random.nextDouble() < GRAY_RELEASE_PERCENT;

    }

}

3.2 第二步：配置拦截器

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

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

import org.springframework.context.annotation.Configuration;

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



@Configuration

public class WebConfig implements WebMvcConfigurer {



    @Autowired

    private GrayReleaseInterceptor grayReleaseInterceptor;



    @Override

    public void addInterceptors(InterceptorRegistry registry) {

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

    }

}

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

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



@RestController

@RequestMapping("/login")

public class LoginController {



    @GetMapping("/v1")

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

        // 旧版本登录逻辑

        return "登录成功 - v1";

    }



    @GetMapping("/v2")

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

        // 新版本登录逻辑

        return "登录成功 - v2";

    }

}

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

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


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

3.4 灰度发布优化

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

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

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

4.1 降低发布风险

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

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

4.2 快速回滚

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

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

4.3 实时监控与反馈

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

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

4.4 提升用户体验

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

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

4.5 支持A/B测试

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

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

4.6 应对复杂的业务需求

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

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

5. 总结

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

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

6. 学习交流

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

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

1. 基础概念

• URL（统一资源定位符） ：用于唯一标识互联网资源，如网页、图片、API等。


• 目录 vs. 资源：
  
  
  
  
  • 以 / 结尾的 URL 通常表示目录，例如：
    
    

    https://example.com/folder/
    
    

    
    
  
  
  • 不以 / 结尾的 URL 通常指向具体的资源（如文件），例如：
    
    

    https://example.com/file
    
    

    
    
  
  
  
  

2. 带 / 和不带 / 的具体区别

（1）目录 vs. 资源

• https://example.com/folder/
  
  
  
  
  • 服务器通常会将其解析为 目录，并尝试返回该目录下的默认文件（如 index.html）。
  
  
  
  


• https://example.com/folder
  
  
  
  
  • 服务器可能会将其视为 文件，如果 folder 不是文件，而是目录，服务器可能会返回 301 重定向到 folder/。
  
  
  
  

📌 示例：

• 访问 https://example.com/blog/
  
  
  
  
  • 服务器可能返回 https://example.com/blog/index.html。
  
  
  
  


• 访问 https://example.com/blog（如果 blog 是个目录）
  
  
  
  
  • 服务器可能重定向到 https://example.com/blog/，再返回 index.html。
  
  
  
  

（2）相对路径解析

URL 末尾是否有 / 会影响相对路径的解析。

假设 HTML 页面包含以下 <img> 标签：

<img src="image.png">

📌 示例：

• 访问 https://example.com/folder/
  
  
  
  
  • 图片路径解析为 https://example.com/folder/image.png
  
  
  
  


• 访问 https://example.com/folder
  
  
  
  
  • 图片路径解析为 https://example.com/image.png
  
  
  • 可能导致 404 错误，因为 image.png 在 folder/ 里，而浏览器错误地去 example.com/ 下查找。
  
  
  
  

原因：

• 以 / 结尾的 URL，浏览器会认为它是一个目录，相对路径会基于 folder/ 解析。


• 不带 /，浏览器可能认为 folder 是文件，相对路径解析可能会出现错误。

（3）SEO 影响

搜索引擎对 https://example.com/folder/ 和 https://example.com/folder 可能会视为两个不同的页面，导致 重复内容问题，影响 SEO 排名。因此：

• 网站通常会选择 一种形式 并用 301 重定向 规范化 URL。


• 例如：
  
  
  
  
  • https://example.com/folder 自动跳转 到 https://example.com/folder/。
  
  
  • 反之亦然。
  
  
  
  

（4）API 请求

对于 RESTful API，带 / 和不带 / 可能导致不同的行为：

• https://api.example.com/users
  
  
  
  
  • 可能返回所有用户数据。
  
  
  
  


• https://api.example.com/users/
  
  
  
  
  • 可能返回 404 或者产生不同的结果（取决于服务器实现）。
  
  
  
  

一些 API 服务器对 / 非常敏感，因此最好遵循 API 文档的规范。

3. 总结

如果你在开发网站，建议：

在日常的软件开发工作中，存储时间是一项基础且常见的需求。无论是记录数据的操作时间、金融交易的发生时间，还是行程的出发时间、用户的下单时间等等，时间信息与我们的业务逻辑和系统功能紧密相关。因此，正确选择和使用 MySQL 的日期时间类型至关重要，其恰当与否甚至可能对业务的准确性和系统的稳定性产生显著影响。

本文旨在帮助开发者重新审视并深入理解 MySQL 中不同的时间存储方式，以便做出更合适项目业务场景的选择。

不要用字符串存储日期

和许多数据库初学者一样，笔者在早期学习阶段也曾尝试使用字符串（如 VARCHAR）类型来存储日期和时间，甚至一度认为这是一种简单直观的方法。毕竟，'YYYY-MM-DD HH:MM:SS' 这样的格式看起来清晰易懂。

但是，这是不正确的做法，主要会有下面两个问题：

DATETIME 和 TIMESTAMP 选择

DATETIME 和 TIMESTAMP 是 MySQL 中两种非常常用的、用于存储包含日期和时间信息的数据类型。它们都可以存储精确到秒（MySQL 5.6.4+ 支持更高精度的小数秒）的时间值。那么，在实际应用中，我们应该如何在这两者之间做出选择呢？

下面我们从几个关键维度对它们进行对比：

时区信息

DATETIME 类型存储的是字面量的日期和时间值，它本身不包含任何时区信息。当你插入一个 DATETIME 值时，MySQL 存储的就是你提供的那个确切的时间，不会进行任何时区转换。

这样就会有什么问题呢？ 如果你的应用需要支持多个时区，或者服务器、客户端的时区可能发生变化，那么使用 DATETIME 时，应用程序需要自行处理时区的转换和解释。如果处理不当（例如，假设所有存储的时间都属于同一个时区，但实际环境变化了），可能会导致时间显示或计算上的混乱。

TIMESTAMP 和时区有关。存储时，MySQL 会将当前会话时区下的时间值转换成 UTC（协调世界时）进行内部存储。当查询 TIMESTAMP 字段时，MySQL 又会将存储的 UTC 时间转换回当前会话所设置的时区来显示。

这意味着，对于同一条记录的 TIMESTAMP 字段，在不同的会话时区设置下查询，可能会看到不同的本地时间表示，但它们都对应着同一个绝对时间点（UTC 时间）。这对于需要全球化、多时区支持的应用来说非常有用。

下面实际演示一下！

建表 SQL 语句：

CREATE TABLE `time_zone_test` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,

  `date_time` datetime DEFAULT NULL,

  `time_stamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

插入一条数据（假设当前会话时区为系统默认，例如 UTC+0）:：

INSERT INTO time_zone_test(date_time,time_stamp) VALUES(NOW(),NOW());

查询数据（在同一时区会话下）：

SELECT date_time, time_stamp FROM time_zone_test;

结果：

+---------------------+---------------------+

| date_time           | time_stamp          |

+---------------------+---------------------+

| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 |

+---------------------+---------------------+

现在，修改当前会话的时区为东八区 (UTC+8):

SET time_zone = '+8:00';

再次查询数据：

# TIMESTAMP 的值自动转换为 UTC+8 时间

+---------------------+---------------------+

| date_time           | time_stamp          |

+---------------------+---------------------+

| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 |

+---------------------+---------------------+

扩展：MySQL 时区设置常用 SQL 命令

# 查看当前会话时区

SELECT @@session.time_zone;

# 设置当前会话时区

SET time_zone = 'Europe/Helsinki';

SET time_zone = "+00:00";

# 数据库全局时区设置

SELECT @@global.time_zone;

# 设置全局时区

SET GLOBAL time_zone = '+8:00';

SET GLOBAL time_zone = 'Europe/Helsinki';

占用空间

下图是 MySQL 日期类型所占的存储空间（官方文档传送门：dev.mysql.com/doc/refman/…）：

在 MySQL 5.6.4 之前，DateTime 和 TIMESTAMP 的存储空间是固定的，分别为 8 字节和 4 字节。但是从 MySQL 5.6.4 开始，它们的存储空间会根据毫秒精度的不同而变化，DateTime 的范围是 58 字节，TIMESTAMP 的范围是 47 字节。

表示范围

TIMESTAMP 表示的时间范围更小，只能到 2038 年：

• DATETIME：'1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'


• TIMESTAMP：'1970-01-01 00:00:01.000000' UTC 到 '2038-01-19 03:14:07.999999' UTC

性能

由于 TIMESTAMP 在存储和检索时需要进行 UTC 与当前会话时区的转换，这个过程可能涉及到额外的计算开销，尤其是在需要调用操作系统底层接口获取或处理时区信息时。虽然现代数据库和操作系统对此进行了优化，但在某些极端高并发或对延迟极其敏感的场景下，DATETIME 因其不涉及时区转换，处理逻辑相对更简单直接，可能会表现出微弱的性能优势。

为了获得可预测的行为并可能减少 TIMESTAMP 的转换开销，推荐的做法是在应用程序层面统一管理时区，或者在数据库连接/会话级别显式设置 time_zone 参数，而不是依赖服务器的默认或操作系统时区。

数值时间戳是更好的选择吗？

除了上述两种类型，实践中也常用整数类型（INT 或 BIGINT）来存储所谓的“Unix 时间戳”（即从 1970 年 1 月 1 日 00:00:00 UTC 起至目标时间的总秒数，或毫秒数）。

这种存储方式的具有 TIMESTAMP 类型的所具有一些优点，并且使用它的进行日期排序以及对比等操作的效率会更高，跨系统也很方便，毕竟只是存放的数值。缺点也很明显，就是数据的可读性太差了，你无法直观的看到具体时间。

时间戳的定义如下：

时间戳的定义是从一个基准时间开始算起，这个基准时间是「1970-1-1 00:00:00 +0:00」，从这个时间开始，用整数表示，以秒计时，随着时间的流逝这个时间整数不断增加。这样一来，我只需要一个数值，就可以完美地表示时间了，而且这个数值是一个绝对数值，即无论的身处地球的任何角落，这个表示时间的时间戳，都是一样的，生成的数值都是一样的，并且没有时区的概念，所以在系统的中时间的传输中，都不需要进行额外的转换了，只有在显示给用户的时候，才转换为字符串格式的本地时间。

数据库中实际操作：

-- 将日期时间字符串转换为 Unix 时间戳 (秒)

mysql> SELECT UNIX_TIMESTAMP('2020-01-11 09:53:32');

+---------------------------------------+

| UNIX_TIMESTAMP('2020-01-11 09:53:32') |

+---------------------------------------+

|                            1578707612 |

+---------------------------------------+

1 row in set (0.00 sec)



-- 将 Unix 时间戳 (秒) 转换为日期时间格式

mysql> SELECT FROM_UNIXTIME(1578707612);

+---------------------------+

| FROM_UNIXTIME(1578707612) |

+---------------------------+

| 2020-01-11 09:53:32       |

+---------------------------+

1 row in set (0.01 sec)

PostgreSQL 中没有 DATETIME

由于有读者提到 PostgreSQL（PG） 的时间类型，因此这里拓展补充一下。PG 官方文档对时间类型的描述地址：http://www.postgresql.org/docs/curren…。

可以看到，PG 没有名为 DATETIME 的类型：

• PG 的 TIMESTAMP WITHOUT TIME ZONE在功能上最接近 MySQL 的 DATETIME。它存储日期和时间，但不包含任何时区信息，存储的是字面值。


• PG 的TIMESTAMP WITH TIME ZONE (或 TIMESTAMPTZ) 相当于 MySQL 的 TIMESTAMP。它在存储时会将输入值转换为 UTC，并在检索时根据当前会话的时区进行转换显示。

对于绝大多数需要记录精确发生时间点的应用场景，TIMESTAMPTZ是 PostgreSQL 中最推荐、最健壮的选择，因为它能最好地处理时区复杂性。

总结

MySQL 中时间到底怎么存储才好？DATETIME?TIMESTAMP?还是数值时间戳？

并没有一个银弹，很多程序员会觉得数值型时间戳是真的好，效率又高还各种兼容，但是很多人又觉得它表现的不够直观。

《高性能 MySQL 》这本神书的作者就是推荐 TIMESTAMP，原因是数值表示时间不够直观。下面是原文：

每种方式都有各自的优势，根据实际场景选择最合适的才是王道。下面再对这三种方式做一个简单的对比，以供大家实际开发中选择正确的存放时间的数据类型：

选择建议小结：

• TIMESTAMP 的核心优势在于其内建的时区处理能力。数据库负责 UTC 存储和基于会话时区的自动转换，简化了需要处理多时区应用的开发。如果应用需要处理多时区，或者希望数据库能自动管理时区转换，TIMESTAMP 是自然的选择（注意其时间范围限制，也就是 2038 年问题）。


• 如果应用场景不涉及时区转换，或者希望应用程序完全控制时区逻辑，并且需要表示 2038 年之后的时间，DATETIME 是更稳妥的选择。


• 如果极度关注比较性能，或者需要频繁跨系统传递时间数据，并且可以接受可读性的牺牲（或总是在应用层转换），数值时间戳是一个强大的选项。

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 提供了更多的控制和灵活性。

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--

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

真快啊！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 新特性概览(重要)

在 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。
  
  
  • 对大表进行分区。
  
  
  
  

如何限制一个账号只能在一处登录

要实现账号单点登录（一处登录限制），需结合 会话管理、实时状态同步 和 冲突处理机制。以下是完整技术方案：

一、核心实现方案

1. 服务端会话控制（推荐）

// 用户登录时生成唯一令牌并记录

public String login(String username, String password) {

    // 1. 验证账号密码

    User user = userService.authenticate(username, password);

  

    // 2. 生成新令牌并失效旧会话

    String newToken = UUID.randomUUID().toString();

    redis.del("user:" + user.getId() + ":token"); // 清除旧token

    redis.setex("user:" + user.getId() + ":token", 3600, newToken);

  

    // 3. 返回新令牌

    return newToken;

}

2. WebSocket实时踢出（增强体验）

// 前端建立长连接

const socket = new WebSocket(`wss://api.example.com/ws?token=${token}`);



socket.onmessage = (event) => {

    if (event.data === 'force_logout') {

        alert('您的账号在其他设备登录');

        location.href = '/logout';

    }

};

3. 登录设备指纹识别

// 生成设备指纹（前端）

function generateDeviceFingerprint() {

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

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

    ctx.textBaseline = 'top';

    ctx.font = "14px Arial";

    ctx.fillText("BrowserFingerprint", 2, 2);

    return canvas.toDataURL().hashCode(); // 简化示例

}



// 服务端校验

if (storedFingerprint != currentFingerprint) {

    forceLogout(storedToken);

}

二、多端适配策略

客户端类型	实现方案
Web浏览器	JWT令牌 + Redis黑名单
移动端APP	设备ID绑定 + FCM/iMessage推送踢出
桌面应用	硬件指纹 + 本地令牌失效检测
微信小程序	UnionID绑定 + 服务端订阅消息

三、关键代码实现

1. JWT令牌增强方案

// 生成带设备信息的JWT

public String generateToken(User user, String deviceId) {

    return Jwts.builder()

        .setSubject(user.getId())

        .claim("device", deviceId) // 绑定设备

        .setExpiration(new Date(System.currentTimeMillis() + 3600000))

        .signWith(SignatureAlgorithm.HS512, secret)

        .compact();

}



// 校验令牌时检查设备

public boolean validateToken(String token, String currentDevice) {

    Claims claims = Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody();

    return claims.get("device").equals(currentDevice);

}

2. Redis实时状态管理

# 使用Redis Hash存储登录状态

def login(user_id, token, device_info):

    # 删除该用户所有活跃会话

    r.delete(f"user_sessions:{user_id}")

  

    # 记录新会话

    r.hset(f"user_sessions:{user_id}", 

           mapping={

               "token": token,

               "device": device_info,

               "last_active": datetime.now()

           })

    r.expire(f"user_sessions:{user_id}", 3600)



# 中间件校验

def check_token(request):

    user_id = get_user_id_from_token(request.token)

    stored_token = r.hget(f"user_sessions:{user_id}", "token")

    if stored_token != request.token:

        raise ForceLogoutError()

四、异常处理机制

场景	处理方案
网络延迟冲突	采用CAS（Compare-And-Swap）原子操作更新令牌
令牌被盗用	触发二次验证（短信/邮箱验证码）
多设备同时登录	后登录者优先，前会话立即失效（可配置为保留第一个登录）

五、性能与安全优化

1. 会话同步优化：

   # Redis Pub/Sub 跨节点同步
   
   PUBLISH user:123 "LOGOUT"
   
   

2. 安全增强：

   // 前端敏感操作二次确认
   
   function sensitiveOperation() {
   
       if (loginTime < lastServerCheckTime) {
   
           showReauthModal();
   
       }
   
   }
   
   

3. 监控看板：

   指标	报警阈值
   并发登录冲突率	>5%/分钟
   强制踢出成功率	<99%

六、行业实践参考

1. 金融级方案：
   • 每次操作都验证设备指纹
   • 异地登录需视频人工审核
2. 社交应用方案：
   • 允许最多3个设备在线
   • 分设备类型控制（手机+PC+平板）
3. ERP系统方案：
   • 绑定特定MAC地址
   • VPN网络白名单限制

通过以上方案可实现：

• 严格模式：后登录者踢出前会话（适合银行系统）
• 宽松模式：多设备在线但通知告警（适合社交应用）
• 混合模式：关键操作时强制单设备（适合电商系统）

部署建议：

1. 根据业务需求选择合适严格度
2. 关键系统增加异地登录二次验证
3. 用户界面明确显示登录设备列表

作者：Epicurus
来源：juejin.cn/post/7485384798569250868

Spring生态重大升级全景图

一、Spring 6.0核心特性详解

1. Java版本基线升级

• 最低JDK 17：全面拥抱Java模块化特性，优化现代JVM性能


• 虚拟线程（Loom项目）：轻量级线程支持高并发场景（需JDK 19+）

// 示例：虚拟线程使用

Thread.ofVirtual().name("my-virtual-thread").start(() -> {

    // 业务逻辑

});

• 
  
  
  
  1. 虚拟线程（Project Loom）
  
  
  
  


• 应用场景：电商秒杀系统、实时聊天服务等高并发场景

// 传统线程池 vs 虚拟线程

// 旧方案（平台线程）

ExecutorService executor = Executors.newFixedThreadPool(200);

// 新方案（虚拟线程）

ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor();

// 处理10000个并发请求

IntStream.range(0, 10000).forEach(i -> 

    virtualExecutor.submit(() -> {

        // 处理订单逻辑

        processOrder(i);

    })

);