1. 业务背景

在前端的业务场景中：点击按钮，发起请求。在请求还未结束的时候，一个按钮可以重复点击，导致接口重新请求多次（如果后端不做限制）。轻则浪费服务器资源，重则业务逻辑错误，尤其是入库操作。

传统解决方案：使用防抖函数，但是无法解决接口响应时间过长的问题，当接口一旦响应时间超过防抖时间，测试单身20年的手速照样还是可以点击多次。

更稳妥的方式：给button添加loadng，只有接口响应结果后才能再次点击按钮。需要在每个使用按钮的页面逻辑中单独维护loading变量，代码变得臃肿。

那如果是在react项目中，这种问题有没有比较优雅的解决方式呢？

vue项目解决方案参考：juejin.cn/post/749541…

2. useAsyncButton

在 React 项目中，对于这种按钮重复点击的问题，可以使用自定义 Hook 来优雅地处理。以下是一个完整的解决方案：

1. 首先创建一个自定义 Hook useAsyncButton：

import { useState, useCallback } from 'react';



interface RequestOptions {

  onSuccess?: (data: any) => void;

  onError?: (error: any) => void;

}



export function useAsyncButton(

  requestFn: (...args: any[]) => Promise,

  options: RequestOptions = {}

) {

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



  const run = useCallback(

    async (...args: any[]) => {

      if (loading) return; // 如果正在加载，直接返回



      try {

        setLoading(true);

        const data = await requestFn(...args);

        options.onSuccess?.(data);

        return data;

      } catch (error) {

        options.onError?.(error);

        throw error;

      } finally {

        setLoading(false);

      }

    },

    [loading, requestFn, options]

  );



  return {

    loading,

    run

  };

}

2. 在组件中使用这个 Hook：

import { useAsyncButton } from '../hooks/useAsyncButton';



const MyButton = () => {

  const { loading, run } = useAsyncButton(async () => {

    // 这里是你的接口请求

    const response = await fetch('your-api-endpoint');

    const data = await response.json();

    return data;

  }, {

    onSuccess: (data) => {

      console.log('请求成功：', data);

    },

    onError: (error) => {

      console.error('请求失败：', error);

    }

  });



  return (

    <button 

      onClick={() => run()} 

      disabled={loading}

    >

    {loading ? '加载中...' : '点击请求'}

  button>

);

};



export default MyButton;

这个解决方案有以下优点：

1. 统一管理：将请求状态管理逻辑封装在一个 Hook 中，避免重复代码
2. 自动处理 loading：不需要手动管理 loading 状态
3. 防重复点击：在请求过程中自动禁用按钮或阻止重复请求
4. 类型安全：使用 TypeScript 提供类型检查
5. 灵活性：可以通过 options 配置成功/失败的回调函数
6. 可复用性：可以在任何组件中重用这个 Hook

useAsyncButton直接帮你进行了try catch,你不用再单独去做异常处理。

是不是很简单？有的人可能有疑问了，为什么下方不就能拿到接口请求以后的数据吗？为什么还需要onSuccess呢？

async () => {

  // 这里是你的接口请求

  const response = await fetch('your-api-endpoint');

  const data = await response.json();

  return data;

}

3. onSuccess

确实我们可以直接在调用 run() 后通过 .then() 或 await 来获取数据。提供 onSuccess 回调主要有以下几个原因：

1. 关注点分离：

// 不使用 onSuccess

const { run } = useAsyncButton(async () => {

  const response = await fetch('/api/data');

  return response.json();

});



const handleClick = async () => {

  const data = await run();

  // 处理数据的逻辑和请求逻辑混在一起

  setData(data);

  message.success('请求成功');

  doSomethingElse(data);

};



// 使用 onSuccess

const { run } = useAsyncButton(async () => {

  const response = await fetch('/api/data');

  return response.json();

}, {

  onSuccess: (data) => {

    // 数据处理逻辑被清晰地分离出来

    setData(data);

    message.success('请求成功');

    doSomethingElse(data);

  }

});



const handleClick = () => {

  run(); // 更清晰的调用方式

};

2. 统一错误处理：

// 不使用 callbacks

const handleClick = async () => {

  try {

    const data = await run();

    setData(data);

  } catch (error) {

    // 每个地方都需要写错误处理

    message.error('请求失败');

  }

};



// 使用 callbacks

const { run } = useAsyncButton(fetchData, {

  onSuccess: (data) => setData(data),

  onError: (error) => message.error('请求失败')

  // 错误处理被集中管理

});

3. 自动重试场景：

const { run } = useAsyncButton(fetchData, {

  onSuccess: (data) => setData(data),

  onError: (error) => {

    if (retryCount < 3) {

      retryCount++;

      run(); // 可以在失败时自动重试

    }

  }

});

4. 状态联动：

const { run } = useAsyncButton(fetchData, {

  onSuccess: (data) => {

    setData(data);

    // 可能需要触发其他请求

    refetchRelatedData();

    // 或更新其他状态

    setOtherState(true);

  }

});

所以，虽然你完全可以不使用 onSuccess 回调，但它能帮助你：

• 更好地组织代码结构
• 统一管理成功/失败处理逻辑
• 方便进行状态联动
• 在需要扩展功能时更加灵活

选择使用与否取决于你的具体需求，如果是简单的场景，直接使用 await run() 也完全可以。

4. 禁止一段时间内点击

评论区有人说了，我要是想在某一段时间内防止重复点击怎么整？

我们可以扩展 useAsyncButton 的功能，添加一个防冷却时间（cooldown）的特性。这在一些特定场景下很有用，比如发送验证码按钮需要等待 60 秒才能再次点击:

import { useState, useCallback, useRef } from 'react';



interface AsyncButtonOptions {

  onSuccess?: (data: any) => void;

  onError?: (error: any) => void;

  cooldown?: number; // 冷却时间（毫秒）

}



export function useAsyncButton(

  requestFn: (...args: any[]) => Promise,

  options: AsyncButtonOptions = {}

) {

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

  const [cooldownRemaining, setCooldownRemaining] = useState(0);

  const timerRef = useRef<NodeJS.Timeout>();



  const startCooldown = useCallback(() => {

    if (!options.cooldown) return;

    

    setCooldownRemaining(options.cooldown / 1000);

    const startTime = Date.now();

    

    timerRef.current = setInterval(() => {

      const elapsed = Date.now() - startTime;

      const remaining = Math.ceil((options.cooldown! - elapsed) / 1000);

      

      if (remaining <= 0) {

        clearInterval(timerRef.current);

        setCooldownRemaining(0);

      } else {

        setCooldownRemaining(remaining);

      }

    }, 1000);

  }, [options.cooldown]);



  const run = useCallback(

    async (...args: any[]) => {

      if (loading || cooldownRemaining > 0) return;



      try {

        setLoading(true);

        const data = await requestFn(...args);

        options.onSuccess?.(data);

        startCooldown();

        return data;

      } catch (error) {

        options.onError?.(error);

        throw error;

      } finally {

        setLoading(false);

      }

    },

    [loading, cooldownRemaining, requestFn, options, startCooldown]

  );



  return {

    loading,

    cooldownRemaining,

    run,

    disabled: loading || cooldownRemaining > 0

  };

}

使用示例：

import { useAsyncButton } from '../hooks/useAsyncButton';



const SendCodeButton = () => {

  const { loading, cooldownRemaining, disabled, run } = useAsyncButton(

    async () => {

      // 发送验证码的接口请求

      const response = await fetch('/api/send-code');

      return response.json();

    },

    {

      cooldown: 60000, // 60秒冷却时间

      onSuccess: () => {

        console.log('验证码发送成功');

      },

      onError: (error) => {

        console.error('验证码发送失败', error);

      }

    }

  );



  return (

    <button 

      onClick={() => run()} 

      disabled={disabled}

    >

      {loading ? '发送中...' : 

       cooldownRemaining > 0 ? `${cooldownRemaining}秒后重试` : 

       '发送验证码'}

    button>

  );

};



export default SendCodeButton;

作者：白哥学前端
来源：juejin.cn/post/7498646341460787211

大家好，我是苏三，又跟大家见面了。

一、传统判空的血泪史

某互联网金融平台因费用计算层级的空指针异常，导致凌晨产生9800笔错误交易。

DEBUG日志显示问题出现在如下代码段：

// 错误示例

BigDecimal amount = user.getWallet().getBalance().add(new BigDecimal("100"));

此类链式调用若中间环节出现null值，必定导致NPE。

初级阶段开发者通常写出多层嵌套式判断：

if(user != null){

    Wallet wallet = user.getWallet();

    if(wallet != null){

        BigDecimal balance = wallet.getBalance();

        if(balance != null){

            // 实际业务逻辑

        }

    }

}

这种写法既不优雅又影响代码可读性。

那么，我们该如何优化呢？

最近准备面试的小伙伴，可以看一下这个宝藏网站：www.susan.net.cn，里面：面试八股文、面试真题、工作内推什么都有。

二、Java 8+时代的判空革命

Java8之后，新增了Optional类，它是用来专门判空的。

能够帮你写出更加优雅的代码。

1. Optional黄金三板斧

// 重构后的链式调用

BigDecimal result = Optional.ofNullable(user)

    .map(User::getWallet)

    .map(Wallet::getBalance)

    .map(balance -> balance.add(new BigDecimal("100")))

    .orElse(BigDecimal.ZERO);

高级用法：条件过滤

Optional.ofNullable(user)

    .filter(u -> u.getVipLevel() > 3)

    .ifPresent(u -> sendCoupon(u)); // VIP用户发券

2. Optional抛出业务异常

BigDecimal balance = Optional.ofNullable(user)

    .map(User::getWallet)

    .map(Wallet::getBalance)

    .orElseThrow(() -> new BusinessException("用户钱包数据异常"));

3. 封装通用工具类

public class NullSafe {

    

    // 安全获取对象属性

    public static <T, R> R get(T target, Function<T, R> mapper, R defaultValue) {

        return target != null ? mapper.apply(target) : defaultValue;

    }

    

    // 链式安全操作

    public static <T> T execute(T root, Consumer<T> consumer) {

        if (root != null) {

            consumer.accept(root);

        }

        return root;

    }

}



// 使用示例

NullSafe.execute(user, u -> {

    u.getWallet().charge(new BigDecimal("50"));

    logger.info("用户{}已充值", u.getId());

});

三、现代化框架的判空银弹

4. Spring实战技巧

Spring中自带了一些好用的工具类，比如：CollectionUtils、StringUtils等，可以非常有效的进行判空。

具体代码如下：

// 集合判空工具

List<Order> orders = getPendingOrders();

if (CollectionUtils.isEmpty(orders)) {

    return Result.error("无待处理订单");

}



// 字符串检查

String input = request.getParam("token");

if (StringUtils.hasText(input)) {

    validateToken(input); 

}

5. Lombok保驾护航

我们在日常开发中的entity对象，一般会使用Lombok框架中的注解，来实现getter/setter方法。

其实，这个框架中也提供了@NonNull等判空的注解。

比如：

@Getter

@Setter

public class User {

    @NonNull // 编译时生成null检查代码

    private String name;

    

    private Wallet wallet;

}



// 使用构造时自动判空

User user = new User(@NonNull "张三", wallet);

四、工程级解决方案

6. 空对象模式

public interface Notification {

    void send(String message);

}



// 真实实现

public class EmailNotification implements Notification {

    @Override

    public void send(String message) {

        // 发送邮件逻辑

    }

}



// 空对象实现

public class NullNotification implements Notification {

    @Override

    public void send(String message) {

        // 默认处理

    }

}



// 使用示例

Notification notifier = getNotifier();

notifier.send("系统提醒"); // 无需判空

7. Guava的Optional增强

其实Guava工具包中，给我们提供了Optional增强的功能。

比如：

import com.google.common.base.Optional;



// 创建携带缺省值的Optional

Optional<User> userOpt = Optional.fromNullable(user).or(defaultUser);



// 链式操作配合Function

Optional<BigDecimal> amount = userOpt.transform(u -> u.getWallet())

                                    .transform(w -> w.getBalance());

Guava工具包中的Optional类已经封装好了，我们可以直接使用。

五、防御式编程进阶

8. Assert断言式拦截

其实有些Assert断言类中，已经做好了判空的工作，参数为空则会抛出异常。

这样我们就可以直接调用这个断言类。

例如下面的ValidateUtils类中的requireNonNull方法，由于它内容已经判空了，因此，在其他地方调用requireNonNull方法时，如果为空，则会直接抛异常。

我们在业务代码中，直接调用requireNonNull即可，不用写额外的判空逻辑。

例如：

public class ValidateUtils {

    public static <T> T requireNonNull(T obj, String message) {

        if (obj == null) {

            throw new ServiceException(message);

        }

        return obj;

    }

}



// 使用姿势

User currentUser = ValidateUtils.requireNonNull(

    userDao.findById(userId), 

    "用户不存在-ID:" + userId

);

最近就业形势比较困难，为了感谢各位小伙伴对苏三一直以来的支持，我特地创建了一些工作内推群， 看看能不能帮助到大家。

你可以在群里发布招聘信息，也可以内推工作，也可以在群里投递简历找工作，也可以在群里交流面试或者工作的话题。

添加苏三的私人微信：li_su223，备注：掘金+所在城市，即可加入。

9. 全局AOP拦截

我们在一些特殊的业务场景种，可以通过自定义注解 + 全局AOP拦截器的方式，来实现实体或者字段的判空。

例如：

@Aspect

@Component

public class NullCheckAspect {

    

    @Around("@annotation(com.xxx.NullCheck)")

    public Object checkNull(ProceedingJoinPoint joinPoint) throws Throwable {

        Object[] args = joinPoint.getArgs();

        for (Object arg : args) {

            if (arg == null) {

                throw new IllegalArgumentException("参数不可为空");

            }

        }

        return joinPoint.proceed();

    }

}



// 注解使用

public void updateUser(@NullCheck User user) {

    // 方法实现

}

六、实战场景对比分析

场景1：深层次对象取值

// 旧代码（4层嵌套判断）

if (order != null) {

    User user = order.getUser();

    if (user != null) {

        Address address = user.getAddress();

        if (address != null) {

            String city = address.getCity();

            // 使用city

        }

    }

}



// 重构后（流畅链式）

String city = Optional.ofNullable(order)

    .map(Order::getUser)

    .map(User::getAddress)

    .map(Address::getCity)

    .orElse("未知城市");

场景2：批量数据处理

List<User> users = userService.listUsers();



// 传统写法（显式迭代判断）

List<String> names = new ArrayList<>();

for (User user : users) {

    if (user != null && user.getName() != null) {

        names.add(user.getName());

    }

}



// Stream优化版

List<String> nameList = users.stream()

    .filter(Objects::nonNull)

    .map(User::getName)

    .filter(Objects::nonNull)

    .collect(Collectors.toList());

七、性能与安全的平衡艺术

上面介绍的这些方案都可以使用，但除了代码的可读性之外，我们还需要考虑一下性能因素。

下面列出了上面的几种在CPU消耗、内存只用和代码可读性的对比：

黄金法则

• Web层入口强制参数校验


• Service层使用Optional链式处理


• 核心领域模型采用空对象模式

八、扩展技术

除了，上面介绍的常规判空之外，下面再给大家介绍两种扩展的技术。

Kotlin的空安全设计

虽然Java开发者无法直接使用，但可借鉴其设计哲学：

val city = order?.user?.address?.city ?: "default"

JDK 14新特性预览

// 模式匹配语法尝鲜

if (user instanceof User u && u.getName() != null) {

    System.out.println(u.getName().toUpperCase());

}

总之，优雅判空不仅是代码之美，更是生产安全底线。

本文分享了代码判空的10种方案，希望能够帮助你编写出既优雅又健壮的Java代码。

这5个项目，太炸裂了

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的50万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

同事：你的代码写的不行啊，不够规范啊。

我：我写的代码怎么可能不规范，不要胡说。

于是同事打开我的 IDEA ，安装了一个插件，然后执行了一下，规范不规范，看报告吧。

这可怎么是好，这玩意竟然给我挑出来这么多问题，到底靠谱不。

同事潇洒的走掉了，只留下我在座位上盯着屏幕惊慌失措。我仔细的查看了这个报告的每一项，越看越觉得这插件指出的问题有道理，果然是我大意了，竟然还给我挑出一个 bug 来。

这是什么插件，review 代码无敌了。

这个插件就是 SonarLint，官网的 Slogan 是 clean code begins in your IDE with {SonarLint}。

作为一个程序员，我们当然希望自己写的代码无懈可击了，但是由于种种原因，有一些问题甚至bug都无法避免，尤其是刚接触开发不久的同学，也有很多有着多年开发经验的程序员同样会有一些不好的代码习惯。

代码质量和代码规范首先肯定是靠程序员自身的水平和素养决定的，但是提高水平的是需要方法的，方法就有很多了，比如参考大厂的规范和代码、比如有大佬带着，剩下的就靠平时的一点点积累了，而一些好用的插件能够时时刻刻提醒我们什么是好的代码规范，什么是好的代码。

SonarLint 就是这样一款好用的插件，它可以实时帮我们 review代码，甚至可以发现代码中潜在的问题并提供解决方案。

SonarLint 使用静态代码分析技术来检测代码中的常见错误和漏洞。例如，它可以检测空指针引用、类型转换错误、重复代码和逻辑错误等。这些都是常见的问题，但是有时候很难发现。使用 SonarLint 插件，可以在编写代码的同时发现这些问题，并及时纠正它们，这有助于避免这些问题影响应用程序的稳定性。

比如下面这段代码没有结束循环的条件设置，SonarLint 就给出提示了，有强迫症的能受的了这红下划线在这儿？

SonarLint 插件可以帮助我提高代码的可读性。代码应该易于阅读和理解，这有助于其他开发人员更轻松地维护和修改代码。SonarLint 插件可以检测代码中的代码坏味道，例如不必要的注释、过长的函数和变量名不具有描述性等等。通过使用 SonarLint 插件，可以更好地了解如何编写清晰、简洁和易于理解的代码。

例如下面这个名称为 hello_world的静态 final变量，SonarLint 给出了两项建议。

SonarLint 插件可以帮助我遵循最佳实践和标准。编写符合标准和最佳实践的代码可以确保应用程序的质量和可靠性。SonarLint 插件可以检测代码中的违反规则的地方，例如不安全的类型转换、未使用的变量和方法、不正确的异常处理等等。通过使用 SonarLint 插件，可以学习如何编写符合最佳实践和标准的代码，并使代码更加健壮和可靠。

例如下面的异常抛出方式，直接抛出了 Exception，然后 SonarLint 建议不要使用 Exception，而是自定义一个异常，自定义的异常可能让人直观的看出这个异常是干什么的，而不是 Exception基本类型导出传递。

安装 SonarLint

可以直接打开 IDEA 设置 -> Plugins，在 MarketPlace中搜索SonarLint，直接安装就可以。

还可以直接在官网下载，打开页面http://www.sonarsource.com/products/so… EXPLORE即可到下载页面去下载了。虽然我们只是在 IDEA 中使用，但是它不只支持 Java 、不只支持 IDEA ，还支持 Python、PHP等众多语言，以及 Visual Studio 、VS Code 等众多 IDE。

在 IDEA 中使用

SonarLint 插件安装好之后，默认就开启了实时分析的功能，就跟智能提示的功能一样，随着你噼里啪啦的敲键盘，SonarLint插件就默默的进行分析，一旦发现问题就会以红框、红波浪线、黄波浪线的方式提示。

当然你也可以在某一文件中点击右键，也可在项目根目录点击右键，在弹出菜单中点击Analyze with SonarLint，对当前文件或整个项目进行分析。

分析结束后，会生成分析报告。

左侧是对各个文件的分析结果，右侧是对这个问题的建议和修改示例。

SonarLint 对问题分成了三种类型

类型说明Bug代码中的 bug，影响程序运行Vulnerability漏洞，可能被作为攻击入口Code smell代码意味，可能影响代码可维护性

问题按照严重程度分为5类

严重性说明BLOCKER已经影响程序正常运行了，不改不行CRITICAL可能会影响程序运行，可能威胁程序安全，一般也是不改不行MAJOR代码质量问题，但是比较严重MINOR同样是代码质量问题，但是严重程度较低INFO一些友好的建议

SonarQube

SonarLint 是在 IDE 层面进行分析的插件，另外还可以使用 SonarQube功能，它以一个 web 的形式展现，可以为整个开发团队的项目提供一个web可视化的效果。并且可以和 CI\CD 等部署工具集成，在发版前提供代码分析。

SonarQube是一个 Java 项目，你可以在官网下载项目本地启动，也可以以 docker 的方式启动。之后可以在 IDEA 中配置全局 SonarQube配置。

也可以在 SonarQube web 中单独配置一个项目，创建好项目后，直接将 mvn 命令在待分析的项目中执行，即可生成对应项目的分析报告，然后在 SonarQube web 中查看。

5

对于绝大多数开发者和开发团队来说，SonarQube 其实是没有必要的，只要我们每个人都解决了 IDE 中 SonarLint 给出的建议，当然最终的代码质量就是符合标准的。

阿里 Java 规约插件

每一个开发团队都有团队内部的代码规范，比如变量命名、注释格式、以及各种类库的使用方式等等。阿里一直在更新 Java 版的阿里巴巴开发者手册，有什么泰山版、终极版，想必各位都听过吧，里面的规约如果开发者都能遵守，那别人恐怕再没办法 diss 你的代码不规范了。

对应这个开发手册的语言层面的规范，阿里也出了一款 IDEA 插件，叫做 Alibaba Java Coding Guidelines，可以在插件商店直接下载。

比如前面说的那个 hello_world变量名，插件直接提示「修正为以下划线分隔的大写模式」。

再比如一些注释上的提示，不建议使用行尾注释。

image-20230314165107639

还有，比如对线程池的使用，有根据规范建议的内容，建议自己定义核心线程数和最大线程数等参数，不建议使用 Excutors工具类。

有了这俩插件，看谁还能说我代码写的不规范了。

今天咱们聊个啥呢？先设想一个场景：你辛辛苦苦开发了一个前端应用，后端 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 提供了更多的控制和灵活性。