Visual Studio Code (VSCode)

是一个由微软开发的免费源代码编辑器，它在开发者社区中非常受欢迎。然而，对于那些寻求完全开源替代方案的人来说，VSCodium 成为了一个不错的选择。下面我将撰写一篇关于 VSCodium 的文章，并阐述它与 VSCode 的主要区别。

VSCodium：自由且开放的开发环境

VSCodium 是一个基于 Visual Studio Code（简称 VSCode）的开源版本控制集成开发环境（IDE）。它不仅提供了与 VSCode 相同的强大功能，还去除了专有软件组件，确保了软件的自由度和透明度。

VSCodium 的特点

• 完全开源：VSCodium 是完全基于 MIT 许可证发布的，这意味着它的源代码是完全公开的，用户可以自由地查看、修改和分发其副本。


• 无数据收集：与 VSCode 不同的是，VSCodium 默认不会发送遥测数据或任何其他信息到微软服务器，这对于注重隐私的开发者来说是一个重要的优势。


• 社区驱动：由于其开源性质，VSCodium 可以通过社区贡献来改进和发展，任何人都可以参与到项目的维护和发展中来。


• 跨平台支持：VSCodium 支持 Windows、macOS 和 Linux 操作系统，为不同平台上的开发者提供了一致的- - 使用体验。

VSCodium 与 VSCode 的主要区别

尽管 VSCodium 和 VSCode 在功能上非常相似，但它们之间存在一些关键差异：

许可证与所有权：

• VSCode 虽然也是免费的，但它使用的是专有的“源码可用”许可证，并且由微软拥有和维护。


• VSCodium 则是完全开源的，遵循 MIT 许可证。

数据收集：

• VSCode 默认会收集一些使用数据，虽然这些数据主要用于改善产品，但对于部分用户来说可能是一个隐私问题。


• VSCodium 去除了所有与数据收集相关的功能，保证用户的隐私不受侵犯。

扩展生态系统：

• VSCode 有一个庞大的官方市场，其中包含了大量的插件和扩展，这使得它成为很多开发者的首选。


• VSCodium 使用相同的扩展格式，但由于其相对较小的用户基数，某些插件可能首先发布在 VSCode 市场上。

更新和支持：

• VSCode 得到了微软的强大支持，通常会有更频繁的更新和新特性发布。


• VSCodium 的更新频率取决于社区贡献者的工作，虽然它通常会紧跟 VSCode 的步伐，但在某些情况下可能会稍微滞后。

下载和安装

github.com/VSCodium/vs…

使用

与vscode基本相同。

结论

选择 VSCodium 还是 VSCode 主要取决于个人的需求和价值观。如果你重视隐私并且希望使用完全开源的工具，那么 VSCodium 将是一个很好的选择。如果你更看重官方支持以及广泛的插件生态系统，那么 VSCode 仍然是一个强大的开发工具。无论选择哪一个，你都将获得一个功能强大、灵活且易于使用的 IDE。

开发桌面应用已经不再是唯一的战场，随着移动设备的普及，跨平台开发成了趋势。最近，Tauri带来了一个让开发者眼前一亮的功能——移动端支持。是的，Tauri不仅能开发轻量级桌面应用，还可以打通移动平台。这就像是它的“王炸”，在保持轻量化和高效的同时，直接扩展到移动端，瞬间吊打许多传统框架。

接下来，我们一起来看看Tauri的移动端支持，如何让它成为开发者的新宠。

1. 从桌面到移动：跨平台的真正意义

首先，我们要明确一点，Tauri的核心竞争力就是跨平台开发。过去它的焦点主要集中在Windows、macOS和Linux三大桌面系统上，能够让你用前端技术快速开发出轻量级桌面应用。如今，它打破了这一界限，开始支持iOS和Android移动端，这让开发者可以在一个统一的框架下，写出同时适配桌面和移动的应用。

对于开发者来说，这意味着更高的开发效率——你不需要为不同的系统做繁琐的适配工作，也不必纠结于不同平台的特性差异。只需要一个代码库，Tauri就能帮你搞定桌面和移动端，真正实现“一次开发，多端运行”。

2. 移动端支持的背后：依然轻量化

说到跨平台框架，大家可能会想到Flutter或者React Native，它们也支持移动端开发，但往往伴随着较大的应用体积和较高的资源消耗。Tauri则依然保持了它一贯的轻量化特性。通过依赖系统自带的WebView，Tauri的应用体积相对其他框架要小得多。

举个例子，同样是一个展示信息的应用，使用Tauri开发的移动端应用安装包可能比Flutter小很多。对用户来说，这种轻量化带来的优势显而易见：更快的下载速度、更少的存储空间占用，尤其适合那些存储空间紧张的设备。

3. 全平台一致的开发体验

Tauri的另一大优势就是它对开发者友好的体验。如果你是前端开发者，你可以继续使用你熟悉的前端技术栈（例如React、Vue、Svelte等），几乎没有学习成本。现在，你不仅能用这些技术来开发桌面应用，还可以直接迁移到移动端，这样的开发一致性大大降低了学习和维护成本。

而且，Tauri的API不仅支持桌面系统的功能调用，现在也在逐步支持移动端的特性。这意味着你可以在同一个代码库中同时调用桌面和移动端的系统功能，而不必为不同的设备写不同的代码。

例如，你可以通过Tauri提供的API来访问手机的传感器、相机等功能，未来它还将进一步扩展对移动端特性的支持。

import { open } from '@tauri-apps/plugin-dialog';

// when using `"withGlobalTauri": true`, you may use

// const { open } = window.__TAURI__.dialog;



// Open a dialog

const file = await open({

  multiple: false,

  directory: false,

});

console.log(file);

// Prints file path or URI

上面的代码不仅可以在桌面应用中运行，未来也能扩展到移动端，实现类似的功能调用。这种开发体验的统一性，对于希望快速上线跨平台应用的开发者来说，绝对是个福音。

4. Tauri在移动端的性能表现

性能问题总是开发者最关心的点。和Flutter这类框架不同，Tauri并没有选择单独构建一个跨平台的UI框架，而是借助操作系统自带的WebView，这样不仅保证了轻量化，还能依托于WebView的优化，带来较好的性能表现。

在移动端，Tauri同样依赖于系统的WebView，这意味着你不必担心额外的资源开销。只要用户的系统WebView版本足够新，应用的启动速度和渲染性能都能得到保障。而且，Tauri团队还在不断优化移动端的支持，未来的性能提升值得期待。

5. 为什么选择Tauri开发移动端应用？

总结一下，如果你是一名前端开发者，或者希望在一个框架下同时支持桌面和移动端，Tauri无疑是一个非常有吸引力的选择。它不仅帮助你用熟悉的前端技术快速开发应用，还通过轻量化设计和跨平台支持，解决了传统框架的种种痛点。

无论是应用体积、性能还是开发体验，Tauri都提供了一个高效且轻量的解决方案。对于那些追求高效开发、同时需要支持桌面和移动端的项目，Tauri的移动端支持就是它的“王炸”。

一些思考：

随着Tauri逐步扩展对移动端的支持，它正从一个桌面应用开发框架，进化为一个真正的全平台开发工具。如果你正在寻找一个轻量化的跨平台解决方案，或者想让你的应用跑在更多设备上，不妨试试Tauri，说不定这就是你一直在找的那个“它”。但是，如果说你的团队准备做一个现象级的产品，可能目前还并不适合，因为 tarui 团队自身看起来也并没有敲定移动端的完美方案，可能后续还会有所调整，追求性能、安全性的同时，还有一个更重要的事情是，兼容性，稳定性，你觉得呢？欢迎留言，掰扯掰扯。

JWT 在 web 开发中作用毋庸置疑。下面我们快速的了解 jwt 在 rust 中的使用。

JWT 基础知识

JWT 是一种用于安全传输信息的轻量级、无状态的标准，适用于身份验证和信息交换场景。通过签名验证和自包含的声明，它能够高效地传递用户信息，同时减少服务器负担。

JWT 组成

Header.Payload.Signature

• Header: 类型（typ）和算法（alg， 指定 hash 签名算法），Header 对象会被比 base64URL 编码。


• Payload：负载部分（事件传递的数据），可以分为三类：注册 Claims、公共 Claims以及私有 Claims,Payload 也会被 base64URL 编码。


• Signature： 签名部分，用于验证消息的完整性，并确保消息在传输过程中未被篡改。

他们直接通过点 . 链接

依赖

[dependencies]

chrono = "0.4.38"

dotenv = "0.15.0"

jsonwebtoken = { version = "9.3.0", features = [] }

serde = { version = "1.0.210", features = ["derive"] }

env 文件

使用 dotenv 将 jwt 需要 secet 放在 env 文件中

JWT_SECRET=your_secret_key

token 的创建和解析

生成解析 token 需要：

• Algorithm 算法


• Claims 有效负载数据。


• chrono 世间处理

实现

jwt 创建和解析十分重要，我们将 jwt 的单独封装到 utils/jwt.rs下

use jsonwebtoken::{encode, decode, Header, Validation, EncodingKey, DecodingKey, Algorithm, TokenData};

use serde::{Serialize, Deserialize};

use chrono::{Utc, Duration};

use std::error::Error;

use std::env;



// Define the claims structure

#[derive(Debug, Serialize, Deserialize)]

pub struct Claims {

    sub: String,          // Subject (user ID, email, etc.)

    exp: usize,           // Expiration time (as UTC timestamp)

}



pub fn create_jwt(sub: &str) -> Result<String, Box<dyn Error>> {

    let secret = env::var("JWT_SECRET").expect("JWT_SECRET must be set");

    // Define some claims

    let my_claims = Claims {

        sub: sub.to_owned(),

        exp: (Utc::now() + Duration::hours(24)).timestamp() as usize, // JWT expires in 24 hours

    };



    // Encoding the token

    let token = encode(

        &Header::default(),

        &my_claims,

        &EncodingKey::from_secret(secret.as_ref()),

    )?;



    Ok(token)

}



pub fn verify_jwt(token: &str) -> Result<TokenData<Claims>, Box<dyn Error>> {

    let secret = env::var("JWT_SECRET").expect("JWT_SECRET must be set");

    let token_data = decode::<Claims>(

        token,

        &DecodingKey::from_secret(secret.as_ref()),

        &Validation::new(Algorithm::HS256),

    )?;

    Ok(token_data)

}

• create_jwt 对外暴露，接受 sub 作为参数，传递给 Claims 结构体。然后使用 encode 进行加密即可。


• verify_jwt 一般是用在请求拦截器中，请求头中 headers 获取 token 进行解析。

小结

本文主要讲解 jwt 在 rust 中使用。本质就是 Claims 对象和 token 创建与解析。我们需要一些 web 组件像 jsonwebtoken、chrono、dotenv 和 serde 等。JWT 往往单独的放在一个单独的 utils 模块中方便能使用时调用。

作者：陈杰

背景

古茗内部有一个 CDN 文件上传平台，用户在平台上传文件时，会将文件上传至阿里云 OSS 对象存储，并将 OSS 链接转换成 CDN 链接返回给用户，即可通过 CDN 链接访问到文件资源。我们对 CDN 文件的缓存策略是持久化强缓存(Cache-Control: public, max-age=31536000)，这就要求所有上传文件的文件名都是唯一的，否则就有文件被覆盖的风险。有哪些方式可以保证文件名全局唯一？

唯一命名方式

方式一：使用时间戳+随机数

这是我们最容易想到的一种方式：

const name = Date.now() + Math.random().toString().slice(2, 6);

// '17267354922380490'

使用时间戳，加上 4 位随机数，已经可以 99.99999% 保证不会存在文件名重复。可以稍微优化一下：

const name = Date.now().toString(36) + Math.random().toString(36).slice(2, 6);

// 'm191x7bii63s'

将时间戳和随机数分别转换成 36 进制，以减少字符串长度。通过上面一步优化可以将字符长度从 17 位减少至 12 位。

使用时间戳+随机数作为文件名的优势是简单粗暴，基本上可以满足述求；但是有极小概率存在文件名冲突的可能。

方式二：使用文件 MD5 值

生成文件的 MD5 Hash 摘要值，在 node 中代码示例如下：

const crypto = require('crypto');

const name = crypto.createHash('md5').update([file]).digest('hex');

// 'f668bd04d1a6cfc29378e24829cddba9'

文件的 MD5 Hash 值可以当成文件指纹，每个文件都会生成唯一的 hash 值（有极小的概率会 hash 碰撞，可以忽略）。使用 MD5 Hash 值作为文件名还可以避免相同文件重复上传；但是缺点是文件名较长。

方式三：使用 UUID

UUID (通用唯一识别码) 是用于计算机体系中以识别信息的一个标识符，重复的概率接近零，可以忽略不计。生成的 UUID 大概长这样：279e573f-c787-4a84-bafb-dfdc98f445cc。

使用 UUID 作为文件名的缺点也是文件名较长。

最终方案

从上述的几种命名方式可以看出，每种方式都有各种的优缺点，直接作为 OSS 的文件命名都不是很满意（期望 CDN 链接尽可能简短）。所以我们通过优化时间戳+随机数方式来作为最终方案版本。

本质上还是基于时间戳、随机数 2 部分来组成文件名，但是有以下几点优化：

• 由于 CDN 链接区分大小写，可以充分利用 数字+大写字母+小写字母（一共 62 个字符），也就是可以转成 62 进制，来进一步缩短字符长度


• 时间戳数字的定义是，当前时间减去 1970-01-01 的毫秒数。显然在 2024 年的今天，这个数字是非常大的。对此，可以使用 当前时间减去 2024-01-01 的毫秒数 来优化，这会大幅减少时间戳数字大小（2024-01-01 这个时间点是固定的，而且必须是功能上线前的一个时间点，确保不会减出负数）

示例代码如下：

/**

 * 10 进制整数转 62 进制

 */

function integerToBase62(value) {

  const base62Chars = '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz';

  const base62 = base62Chars.length;

  value = parseInt(value);

  if (isNaN(value) || !value) {

    return String(value);

  }



  let prefix = '';

  if (value < 0) {

    value = -value;

    prefix = '-';

  }



  let result = '';

  while (value > 0) {

    const remainder = value % base62;

    result = base62Chars[remainder] + result;

    value = Math.floor(value / base62);

  }



  return prefix + result || '0';

}



const part1 = integerToBase62(Date.now() - new Date('2024-01-01').getTime()); // 'OkLdmK'

const part2 = integerToBase62(Math.random() * 1000000).slice(-4); // '3hLT'

const name = part1 + part2; // 'OkLdmK3hLT'

最终文件名字符长度减少到 10 位。但是始终感觉给 4 位随机数太浪费了，于是想着能否在保证唯一性的同时，还能减少随机数的位数。那就只能看看时间戳部分还能不能压榨一下。

只要能保证同一毫秒内只生成一个文件的文件名，就可以保证这个文件名是唯一的，这样的话，随机数部分都可以不要了，所以可以做如下优化：

// 伪代码

async function getFileName() {

  // 等待锁释放，并发调用时保证至少等待 1ms

  await waitLockRelease();



  return integerToBase62(Date.now() - new Date('2024-01-01').getTime());

}



const name = await getFileName();

// 'OkLdmK'

由于 node 服务线上是多实例部署，所以 waitLockRelease 方法是基于 Redis 来实现多进程间加锁，保证多进程间创建的文件名也是唯一的。与此同时，还额外加上了一位随机数，来做冗余设计。最终将文件名字符长度减少至 7 位，且可以 100% 保证唯一性！

总结

看似非常简单的一个问题，想要处理的比较严谨和完美，其实也不太容易，甚至引入了 62 进制编码及加锁逻辑的处理。希望本文的分享能给大家带来收获！

这里每天分享一个 iOS 的新知识，快来关注我吧

前言

在 iOS App 开发中，推送通知是一个非常有效地触答和吸引用户的措施，通知可以成为让用户保持用户的参与度。

但大家都知道，苹果上每个 App 想要发推送给用户，都需要首先申请对应的权限，只有用户明确点了允许之后才可以。

大部分的 App 都是在启动时直接申请权限，这样的话，用户可能会因为不了解 App 的情况而拒绝授权，就会导致 App 无法发送通知。

其实在 iOS 12 中有个方案叫做临时通知。这功能允许应用在没有申请到权限的情况下发送通知。

今天就来聊聊这个不为人知的隐藏功能。

请求临时授权

要请求临时授权，我们需要使用与请求完全授权相同的方法 requestAuthorization(options:completionHandler:)，但需要添加 provisional 选项。

let center = UNUserNotificationCenter.current()

center.requestAuthorization(options: [.alert, .sound, .badge, .provisional]) { isSuccess, error in

    if let error {

        print("Error requesting notification authorization: \(error)")

    } else if isSuccess {

        print("Requesting notification authorization is successed")

    } else {

        print("Requesting notification authorization is failed")

    }

}

如果不加 provisional 选项，那么当你调用这个方法时，会直接弹出授权弹窗：

加 provisional 选项后这段代码不会触发对话框来提示用户允许通知。它会在首次调用时静默地授予我们的应用通知权限。

由于用户无感知，所以我们不必等待合适的时机来请求授权，可以在应用一启动时就调用。

发送通知

为了展示我们应用通知对用户的确是有价值的，我们可以开始通过本地或远程通知来定位用户。这里我们将发送一个本地通知作为示例，但如果你想尝试远程推送通知，可以查看我之前的几篇文章。

使用 iOS 模拟器测试推送

Xcode 14 模拟器支持远程推送

为了测试临时通知流程，以下是发送一个将在设置后 10 秒触发的本地通知的示例：

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

    

    let center = UNUserNotificationCenter.current()

    center.requestAuthorization(options: [.alert, .sound, .badge, .provisional]) { isSuccess, error in

        if let error {

            print("Error requesting notification authorization: \(error)")

        } else if isSuccess {

            print("Requesting notification authorization is successed")

            self.scheduleTestNotification()

        } else {

            print("Requesting notification authorization is failed")

        }

    }

    

    return true

}



func scheduleTestNotification() {

    let content = UNMutableNotificationContent()

    content.title = "发现新事物！"

    content.body = "点击探索你还未尝试的功能。"

    

    let trigger = UNTimeIntervalNotificationTrigger(

        timeInterval: 10,

        repeats: false

    )

    let request = UNNotificationRequest(

        identifier: UUID().uuidString,

        content: content,

        trigger: trigger

    )

    

    UNUserNotificationCenter.current().add(request) { error in

        if let error = error {

            print("Error scheduling notification: \(error)")

        }

    }

}

启动 App 后，我们退回到后台，等待 10 秒后，会看到我们发的通知已经出现在了通知中心中了。

此时可以看到这条通知中下边会出现两个按钮，如果用户想继续接受，就会点击继续接收按钮，如果不想继续接受，就会点击停止按钮。

如果用户点了停止按钮，那么就相当于我们应用的通知权限被用户拒绝了，相反的，如果用户点击了继续接收按钮，那么就相当于我们应用的通知权限被用户接受了。

鼓励用户完全授权

因此这条通知决定了用户是否继续接收我们 App 的通知，那么我们就需要慎重考虑这条通知的文案和时机，在用户体验到我们通知的好处之后，再发送这个通知，这样用户大概率就会选择继续接收通知。

如果用户仍然选择拒绝授权，我们还可以在 App 内的合适位置引导用户到设置页面去手动开启。

我这里写一个简单的示例，大家可以参考，先判断是否有权限，然后引导用户去设置页面。

class EnableNotificationsViewController: UIViewController {

    

    private let titleLabel: UILabel = {

        let label = UILabel()

        label.text = "启用通知提示"

        label.textAlignment = .center

        label.font = UIFont.systemFont(ofSize: 20, weight: .bold)

        label.translatesAutoresizingMaskIntoConstraints = false

        return label

    }()

    

    private let descriptionLabel: UILabel = {

        let label = UILabel()

        label.text = "启用通知横幅和声音，保持最新了解我们的应用提供的一切。"

        label.textAlignment = .center

        label.numberOfLines = 0

        label.translatesAutoresizingMaskIntoConstraints = false

        return label

    }()

    

    private let settingsButton: UIButton = {

        let button = UIButton(type: .system)

        button.setTitle("去设置", for: .normal)

        button.setTitleColor(.white, for: .normal)

        button.backgroundColor = .systemBlue

        button.layer.cornerRadius = 8

        button.translatesAutoresizingMaskIntoConstraints = false

        return button

    }()

    

    override func viewDidLoad() {

        super.viewDidLoad()

        setupUI()

    }

    

    private func setupUI() {

        view.backgroundColor = .white

        

        view.addSubview(titleLabel)

        view.addSubview(descriptionLabel)

        view.addSubview(settingsButton)

        

        NSLayoutConstraint.activate([

            titleLabel.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 20),

            titleLabel.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20),

            titleLabel.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20),

            

            descriptionLabel.topAnchor.constraint(equalTo: titleLabel.bottomAnchor, constant: 20),

            descriptionLabel.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 20),

            descriptionLabel.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -20),

            

            settingsButton.topAnchor.constraint(equalTo: descriptionLabel.bottomAnchor, constant: 30),

            settingsButton.centerXAnchor.constraint(equalTo: view.centerXAnchor),

            settingsButton.widthAnchor.constraint(equalToConstant: 120),

            settingsButton.heightAnchor.constraint(equalToConstant: 44)

        ])

        

        settingsButton.addTarget(self, action: #selector(openSettings), for: .touchUpInside)

    }

    

    @objc private func openSettings() {

        if let url = URL(string: UIApplication.openSettingsURLString) {

            UIApplication.shared.open(url)

        }

    }

}



// 检查通知权限

func checkNotificationAuthorization() {

    let center = UNUserNotificationCenter.current()

    center.getNotificationSettings { settings in

        if settings.authorizationStatus == .authorized {

            print("Notification authorization is authorized")

        } else {

            print("Notification authorization is not authorized")

        }

    }

}

最后

在我们的应用中实现临时通知是一种吸引用户的好方法，这其实也是苹果推荐的做法，创建一种尊重用户偏好的非侵入性通知体验，同时展示你应用通知的价值。

希望这篇文章对你有所帮助，如果你喜欢这篇文章，欢迎点赞、收藏、评论和转发，我们下期再见。

这里每天分享一个 iOS 的新知识，快来关注我吧

本文同步自微信公众号 “iOS新知”，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！

大家好，我是前端西瓜哥。

opentype.js 是一个 JavaScript 库，支持浏览器和 Node.js，可以解析字体文件，拿到字体信息，并提供一些渲染方法。

虽然名字叫做 opentype.js，但除了可以解析 OpenType，也可以解析 TrueType。

支持常见的字体类型，比如 WOFF, OTF, TTF。像是 AutoCAD 的 shx 就不支持了。

本文使用的 opentype.js 版本为 1.3.4

加载文字

加载文件字体为二进制数据，然后使用 opentype.js 解析：

import opentype from 'opentype.js'



const buffer = await fetch('./SourceHanSansCN-Normal.otf').then(

  (res) => res.arrayBuffer(),

);



const font = opentype.parse(buffer);

需要注意的是，woff2 字体是用 Brotli 压缩过的文件，需要你额外用解压库做解压。

opentype.js 没有提供对应解压 Brotli 的能力，倒是提供了 Inflate 解压能力，所以可以解析 woff 字体。

font 这个对象保存了很多属性。

比如所有的 glyph（字形）、一些 table（表）、字体的信息（字体名、设计师等）等等。

获取字形（glyph）信息

glyph 为单个需要渲染的字形，是渲染的最小单位。

const glyph = font.charToGlyph('i')

另外 stringToGlyphs 方法会返回一个 glyph 数组。

const glyphs = font.stringToGlyph('abcd');

获取文字轮廓（path）

getPaths 计算得到一段字符串中每个 glyph 的轮廓数据。传入的坐标值为文字的左下角位置和文字大小。

const x = 60;

const y = 60;

const fontSize = 24;

const text = '前端西瓜哥/Ab1';



const textPaths = font.getPaths(text, x, y, fontSize);

textPaths 是一个 path 数组。

字符串长度为 9，产生了 9 个 glyph（字形），所以一共有 9 个 path 对象。

形状的表达使用了经典的 SVG 的 Path 命令，对应着 command 属性。

TrueType 字体的曲线使用二阶贝塞尔曲线（对应 Q 命令）；而 OpenType 支持三阶贝塞尔曲线（对应 C 命令）。

渲染

我们有了 Path 数据，就能渲染 SVG 或 Canvas。

当然这个 OpenType.js 专门暴露了方法给我们，不用自己折腾做这层转换实现。

Canvas

基于 Canvas 2D 的方式绘制文字。

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

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



// ...



font.draw(ctx, text, x, y, fontSize);

渲染效果：

如果使用的字体找不到对应的字形，比如只支持英文的字体，但是却想要渲染中文字符。

此时 opentype.js 会帮你显示一个 豆腐块（“tofu” glyph）。豆腐块是取自字体自己设定的 glyph，不同字体的豆腐块还长得不一样，挺有意思的。

辅助点和线

字体是基于直线和贝塞尔曲线控制点形成的轮廓线进行表达的，我们可以绘制字体的控制点：

font.drawPoints(ctx, text, x, y, fontSize);

对文字做度量（metrics）得到尺寸数据。蓝色线为包围盒，绿色线为前进宽度。

font.drawMetrics(ctx, text, x, y, fontSize);

SVG

Path 实例有方法可以转为 SVG 中 Path 的 pathData 字符串。（Glyph 对象也支持这些方法）

path 长这个样子：

"M74.5920 47.6640L74.5920 57.5040L76.1040 57.5040L76.1040 47.6640ZM79.4640 46.9200L79.4640 59.8080C79.4640 60.1440 79.3440 60.2400 78.9600 60.2640C78.5520 60.2880 77.2320 60.2880 75.7440 60.2400C75.9840 60.6720 76.2480 61.3440 76.3200 61.7760Z"

拿到一段字符串对应的 path。

const textPath = font.getPath(text, x, y, fontSize);

const pathData = textPath.toPathData(4); // 4 为小数精度



// 创建 path 元素，指定 d 属性，添加到 SVG 上...

渲染结果。

另外还有一个 getPaths 方法，会返回一个 path 数组，里面是每个 glyph 的 path。

也可以直接拿到一个 path 元素的字符串形式。

path.toSVG(4)

会返回类似这样的字符串：

<path d="M74.5920 47.6640L74.5920 57.5040L76.1040 57.5040L76.1040 47.6640ZM79.4640 46.9200L79.4640 59.8080C79.4640 60.1440 79.3440 60.2400 78.9600 60.2640C78.5520 60.2880 77.2320 60.2880 75.7440 60.2400C75.9840 60.6720 76.2480 61.3440 76.3200 61.7760Z"/>

连字（ligature）

连字（合字、Ligatrue），指的是能够将多个字符组成成一个字符（glyph）。如：

像是 FiraCode 编程字体，该字体会将一些符号进行连字。

opentype.js 虽然说自己支持连字（Support for ligatures），但实际测试发现 API 好像并不会做处理。

用法为：

const textPath = font.getPath(text, x, y, fontSize, {

  features: { liga: true },

});

字距（kerning）

两个 glyph 的距离如果为 0，会因为负空间不均匀，导致视觉上的失衡。

此时字体设计师就会额外调整特定 glyph 之间的字距（kerning），使其空间布局保持均衡。如下图：

opentype.js 可以帮我们获取两个 glyph 之间的字距。

const leftGlyph = font.charToGlyph('A');

const rightGlyph = font.charToGlyph('V');



font.getKerningValue(leftGlyph, rightGlyph)

// -15

返回值为 -15。代表右侧的字形 V 需往左移动 15 的距离。

结尾

本文简单介绍了 opentype.js 的一些用法，更多用法可以阅读官方文档。

不过你大概发现里面有某些方法对不上号，应该是迟迟未发布的 2.0.0 版本的文档。所以正确做法是切为 1.3.4 分支阅读 README.md 文档。

我是前端西瓜哥，关注我学习更多前端知识。

引言

在数字技术的浪潮中，编程语言始终扮演着至关重要的角色。Java，自1995年诞生以来，便以其跨平台的特性和丰富的生态系统，成为了全球范围内开发者们最为青睐的编程语言之一

然而，随着技术的不断进步和新兴语言的崛起，近年来，“Java已死”的论调开始不绝于耳。尤其是在大模型技术迅猛发展的今天，Java的地位似乎更加岌岌可危。然而，事实真的如此吗？Java的春天，真的已经渐行渐远了吗？本文将从多个维度深入探讨Java的现状、大模型技术的影响，以及Java与大模型融合的可能性，为读者提供一个更为全面和深入的视角。

Java的辉煌历史与稳健地位

Java，作为Sun Microsystems在1995年推出的编程语言，一经问世便凭借其独特的跨平台特性和丰富的生态系统，迅速在全球范围内赢得了广泛的认可和应用。从最初的Java Applet，到后来的Java Web开发、Java EE企业级应用，再到如今的Android应用开发、大数据处理等领域，Java都展现出了其强大的生命力和广泛的应用前景。

在最新的TIOBE编程语言排行榜上，Java长期位居前列，这足以证明其在开发界的重要地位。而在中国这个拥有庞大IT市场的国家中，Java更是受到了广泛的关注和追捧。无论是大型企业还是初创公司，Java都成为了其首选的开发语言之一。这背后，是Java的跨平台特性、丰富的库和框架、强大的社区支持等多方面的优势所共同铸就的。

然而，随着技术的不断进步和新兴语言的崛起，Java也面临着一些挑战和质疑。

一些人认为，Java的语法过于繁琐、性能不够优越、新兴语言如Python、Go等更加轻便灵活。这些观点在一定程度上反映了Java在某些方面的不足和局限性。

但是，我们也不能忽视Java在企业级应用、Web开发、大数据处理等领域的深厚积累和广泛应用。这些领域对Java的稳定性和可靠性有着极高的要求，而Java正是凭借其在这方面的优势，赢得了众多企业和开发者的青睐。

大模型技术的崛起与影响

近年来，随着人工智能和机器学习技术的飞速发展，大模型技术逐渐成为了人工智能领域的一大热点，可谓是百家争鸣。大模型技术通过构建庞大的神经网络模型，实现对海量数据的深度学习和处理，从而在各种应用场景中取得了令人瞩目的成果。

在自然语言处理领域，大模型技术通过训练庞大的语言模型，实现了对自然语言的深入理解和生成。这使得机器能够更加智能地处理人类的语言信息，从而实现更加自然和流畅的人机交互。在图像处理领域，大模型技术也展现出了强大的能力。通过训练庞大的卷积神经网络模型，机器能够实现对图像的精准识别和分析，从而在各种应用场景中发挥出巨大的作用。

大模型技术的崛起对软件开发产生了深远的影响。

首先，大模型技术为开发者提供了更加高级别的抽象和智能化解决方案。这使得开发者能够更加专注于核心业务逻辑的实现，而无需过多关注底层技术的细节。其次，大模型技术降低了AI应用的开发门槛。传统的AI应用开发需要深厚的数学和编程基础，而大模型技术则通过提供易于使用的工具和框架，使得开发者能够更加方便地构建和部署AI应用。最后，大模型技术推动了软件开发的智能化升级。从需求分析、设计到开发、测试和维护等各个环节都在经历着智能化的变革，这使得软件开发过程更加高效和智能。

Java与大模型的融合与变革

在大模型技术崛起的背景下，Java作为一种成熟且广泛应用的编程语言，自然也在探索与大模型技术的融合之路。事实上，Java与大模型的融合已经取得了不少进展和成果。

首先，Java社区对于大模型技术的支持和探索已经初见成效。一些开源项目和框架在Java环境中实现了深度学习和大模型技术的支持，如Deeplearning4j、ND4J等。这些项目和框架为Java开发者提供了丰富的工具和资源，使得他们能够更加方便地构建和部署基于大模型的应用。

其次，Java自身的特性和优势也为其与大模型的融合提供了有力的支持。Java作为一种面向对象的语言，具有强大的抽象能力和封装性，这使得它能够更好地处理大模型中的复杂数据结构和算法。同时，Java的跨平台特性也使得基于Java的大模型应用能够在不同的操作系统和硬件平台上运行，从而提高了应用的兼容性和可移植性。

最后，Java与大模型的融合也推动了软件开发的智能化升级。在需求分析阶段，大模型技术可以通过对海量数据的学习和分析，帮助开发者更加准确地把握用户需求和市场趋势。在设计阶段，大模型技术可以通过对已有设计的分析和优化，提高设计的合理性和效率。在开发阶段，大模型技术可以为开发者提供智能化的编程辅助和错误检查功能，从而提高开发效率和代码质量。在测试和维护阶段，大模型技术可以通过对应用的持续监控和分析，及时发现和修复潜在的问题和缺陷。

未来趋势与展望

随着AI和机器学习技术的不断发展，大模型技术将在未来继续发挥重要的作用。而Java作为一种成熟且广泛应用的编程语言，也将继续在大模型时代发挥其独特的优势和作用。

首先，Java将继续优化其性能和语法，提高开发者的开发效率和代码质量。同时，Java还将加强对大模型技术的支持和整合，为开发者提供更加全面和强大的工具和框架。

其次，Java将与更多新兴技术进行融合和创新。例如，随着云计算和边缘计算的兴起，Java将加强与这些技术的融合，推动云计算和边缘计算应用的发展。此外，Java还将与物联网、区块链等新兴技术进行深度融合，开拓新的应用领域和市场空间。

最后，Java将继续发挥其在企业级应用、Web开发、大数据处理等领域的优势，为各行各业提供更加稳定、可靠、安全的解决方案。同时，Java也将积极拥抱开源文化和社区文化，与全球开发者共同推动Java生态系统的繁荣和发展。

总之，Java作为一种历久弥新的编程语言巨头，将在大模型时代继续发挥其独特的优势和作用。通过与大模型技术的深度融合与创新，Java将引领编程世界的潮流，为各行各业带来更加智能化和自动化的解决方案。让我们共同期待Java在未来的辉煌！

写在最后

我不禁要感慨Java这一编程语言的深厚底蕴和持久魅力。它不仅是一段技术史，更是无数开发者智慧与汗水的结晶。在大模型时代，Java也会以其独特的稳定性和可靠性，持续为各行各业提供着坚实的支撑。正如历史的河流永不停息，Java也在不断地进化与创新，与新兴技术深度融合，共同推动着科技发展的浪潮。让我们携手前行，继续书写Java的辉煌篇章，为构建更加智能、更加美好的未来贡献力量。

引言

最近在一些论坛上，有人讨论 setTimeout 的准确性。因此，我进行了探索，以解答这个问题。结果发现，setTimeout 并不完全可靠，因为它是一个宏任务。所指定的时间实际上是将任务放入主线程队列的时间，而不是任务实际执行的时间。

`setTimeout(callback, 进入主线程的时间)`

因此，何时执行回调取决于主线程上待处理的任务数量。

演示

这段代码使用一个计数器来记录每次 setTimeout 的调用。设定的间隔时间乘以计数次数，理想情况下应等于预期的延迟。通过以下示例，可以检查我们计时器的准确性。

function time () {

    var speed = 50, // 间隔

    count = 1 // 计数

    start = new Date().getTime();



    function instance() {

        var ideal=(count * speed),

        real = (new Date().getTime() - start);



        count++;

        console.log(count + '理想值------------------------：', ideal); // 记录理想值

        console.log(count + '真实值------------------------：', real); // 记录理想值



        var diff = (real - ideal);

        console.log(count + '差值------------------------：', diff); // 差值

        

        // 小于5执行

        if (count < 5) {

            window.setTimeout(function(){

                instance();

            }, speed);

        };

        

    };



    window.setTimeout(function () {

        instance();

    }, speed);

};

打印1

我们可以在 setTimeout 执行之前加入额外的代码逻辑，然后再观察这个差值。

...

window.setTimeout(function(){

    instance();

}, speed);

for(var a = 1, i = 0; i < 10000000; i++) { 

    a *= (i + 1); 

};

...

打印2

可以看出，这大大增加了误差。随着时间的推移，setTimeout 实际执行的时间与理想时间之间的差距会不断扩大，这并不是我们所期望的结果。在实际应用中，例如倒计时和动画，这种时间偏差会导致不理想的效果。

如何实现更精准的 setTimeout？

requestAnimationFrame

window.requestAnimationFrame() 告诉浏览器——你希望执行一个动画，并且要求浏览器在下次重绘之前调用指定的回调函数更新动画。

该方法需要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行，回调函数执行次数通常是每秒60次，也就是每16.7ms 执行一次，但是并不一定保证为 16.7 ms。

我们用requestAnimationFrame模拟 setTimeout

function setTimeout2(cb, delay) {

    const startTime = Date.now();



    function loop() {

        const now = Date.now();

        if (now - startTime >= delay) {

            cb();

        } else {

            requestAnimationFrame(loop);

        }

    }



    requestAnimationFrame(loop);

};

打印3

貌似误差问题还是没有得到解决，因此这个方案还是不行。

while

想得到准确的，我们第一反应就是如果我们能够主动去触发，获取到最开始的时间，以及不断去轮询当前时间，如果差值是预期的时间，那么这个定时器肯定是准确的，那么用while可以实现这个功能。

function time2(time) {

    const startTime = Date.now();

    

    function checkTime() {

        const now = Date.now();

        if (now - startTime >= time) {

            console.log('误差', now - startTime - time);

        } else {

            setTimeout(checkTime, 1); // 每毫秒检查一次

        }

    }



    checkTime();

}



time2(5000);

误差存在是 2, 甚至为 0, 但使用 while(true) 会导致 CPU 占用率极高，因为它会持续循环而不进行任何等待，会使得页面进入卡死状态，这样的结果显然是不合适的。

setTimeout 系统时间补偿

这个方案是在 Stack Overflow 看到的一个方案，我们来看看此方案和原方案的区别。

当每一次定时器执行时后，都去获取系统的时间来进行修正，虽然每次运行可能会有误差，但是通过系统时间对每次运行的修复，能够让后面每一次时间都得到一个补偿。

function time () {

    var speed = 50, // 间隔

    count = 1 // 计数

    start = new Date().getTime();



    function instance() {

        var ideal=(count * speed),

        real = (new Date().getTime() - start);



        count++;

        console.log(count + '理想值------------------------：', ideal); // 记录理想值

        console.log(count + '真实值------------------------：', real); // 记录理想值



        var diff = (real - ideal);

        console.log(count + '差值------------------------：', diff); // 差值

        

        // 5次后不再执行

        if (count < 5) {

            window.setTimeout(function(){

                instance();

            }, (speed - diff));

        };

    };



    window.setTimeout(function () {

        instance();

    }, speed);

};

打印4

结论

多次尝试后，是非常稳定的，误差微乎其微，几乎可以忽略不计，因此通过系统的时间补偿，能使 setTimeout 变得更加准时。

背景

大家好，我是程序员 cq。

最近快国庆节了，很多平台为了促销都开始发放优惠券，连上海都发放了足足 5 亿元的消费券，当知道这个消息的时候，我差点都忘了自己没钱的事了。

言归正传，我们 网站 也准备做一个优惠券的功能，正好借此机会给大家分享下我们是怎么做的优惠券，下面是某一次需求评审会的对话：

产品小 y：最近国庆节快到了，咱们网站也要像其他网站学习，给用户发放优惠券，把我们的价格打下来！

开发小 c：我才不做，你直接把会员价格下调不就好了？要啥优惠券，不做不做。

产品小 y：诶，你这个小同志，我下调价格是简单，但是我下调之后怎么统计有多少人看了我们的商品没买呢（转化率）？

开发小 c：你统计这个干什么，让用户感觉到优惠不就行了？

产品小 y：我统计转化率肯定是有意义的呀，我给不同的推广渠道发放不同的优惠券，可以得到不同渠道的转化率，如果有的渠道转化率很差，那我下次就不在这个渠道里推广了，有的渠道转化率很好，那我后面就要在这个渠道里加大推广量。还有就是我直接改价要手动改，假期人工改价格很难保证准时开始活动。

开发小 c：好像有道理啊，而且直接改价格也会让用户感觉平台的价格不稳定，价格经常变动，导致用户总是处于观望的状态。

技术方案

需求分析

既然上面需求评审确定了我们要做优惠券功能，那我们就要先梳理下我们要做什么东西。

首先就是优惠券的优惠能力，我们第一期就做的简单些，只用完成直减券，也就是购买会员的时候可以直接抵扣金额的消费券。当然实际上优惠券不光有直减券，还有满减券、折扣券等等，我们的网站也不需要那么复杂，能做一个直减券就够应对会员降价的功能了。

其次就是优惠券的开始时间和结束时间，便于控制优惠的开始时间和结束时间。

最后还有对应的使用条件，比如我们的优惠券只允许新用户使用，便于拉新，之类的。

那我们就可以确定这个优惠券只需要有减免价格、优惠券名称、开始结束时间以及使用条件就好了。

这时候网站运营同学听到我的喃喃低语，头突然伸过来。

他高呼：你这样可不行啊，光有这些可不够，我还要有优惠券的浏览量、领取量、使用量算转化率的嘞！

我心神一动，喔喔喔，那这样的话就可以做一个漏斗：浏览量 > 领取量 > 使用量，「使用量 / 领取量」就可以得到这个优惠券的转化率，也就知道了这个营销渠道的效果。

想到这里，我果断开口，好好好，就宠你。

具体实现

ok，我们确定了我们要做的内容，也就是要给会员商品做一个优惠券，其中要可以控制减免的金额、优惠券的浏览量、领取量、使用量、还有优惠券的开始时间、结束时间以及使用条件。

业务流程

明确了要做的需求，那么我们就可以确定下我们的整个业务流程：

技术实现

其实上述流程中最复杂的地方还是用户领取优惠券和使用优惠券购买后的处理逻辑，下面我带大家看下我们都是怎么做的。

首先我们要对领取优惠券做幂等，确保用户只在第一次领取优惠券的时候可以领取成功，后续的领取都返回已领取。要实现这个效果，我们需要对用户领取优惠券加锁，也就是下面这样：

String lockKey = "coupon_receive_lock:" + userId + ":" + couponId;

synchronized (lockKey.intern()) {

    couponService.receiveCouponInner(loginUser, coupon);

}

但是由于我们公司是一个分布式的服务，所以本地锁其实是无效的，正好我们的服务用到了 redis，而且还引入了 redisson，那么就可以直接使用 redisson 的分布式锁，

String lockKey = RedisKeyConstant.COUPON_RECEIVE_LOCK + userId + ":" + couponId;

RLock lock = redissonClient.getLock(lockKey);

try {

    lock.lock();

    return couponService.receiveCouponInner(loginUser, coupon);

} finally {

    lock.unlock();

}

但是这样写就太 low 了，我不如直接封装一个方法，让后续再使用分布式锁更方便：

public  T blockExecute(String lockKey, Supplier supplier) {

    RLock lock = redissonClient.getLock(LOCK_KEY_PREFIX + lockKey);

    try {

        lock.lock();

        // 执行方法

        return supplier.get();

    } finally {

        lock.unlock();

    }

}

这样，我们在使用分布式锁的时候就更方便了：

String lockKey = RedisKeyConstant.COUPON_RECEIVE_LOCK + userId + ":" + couponId;

return redisLockUtil.blockExecute(lockKey,

                () -> couponService.receiveCouponInner(loginUser, coupon));

很好，在完成需求的时候又做了个基建工作，不愧是我。

其次就是在用户领取优惠券之后，我们的优惠券库存就应该对应的 -1，同时领取量对应 +1，那么这个 sql 就是这样的：

update coupon set leftNum = leftNum - 1, receiveNum = receiveNum + 1 where id = ?

这里可以确定数据不会出现混乱，因为在执行更新操作的时候，mysql 会有行锁，所以所有领取的用户都会在这里进行排队操作。

但是这样反而会出现问题，如果一瞬间领取优惠券的用户量激增，大家都在排队等库存量 - 1，就导致领取优惠券的时候用户会感觉很卡，也就是我们常说的热点行问题，不过像很多云厂商，都会针对热点行进行优化，比如某某云的 Inventory Hint 就可以实现快速提交 / 回滚事务，提高吞吐量，详细文章可以看下这篇文章：Inventory Hint，如果并发量真的很大的话，可以考虑用 redis 实现库存的 - 1，不过按照以往的经验来说不用 redis 也可以扛得住，这里就没必要再搞那么复杂了。

最后在领取优惠券之后，我们要接收来自支付中心的回调，根据用户的支付信息给用户赋予对应的会员权限，同时设置用户领取的优惠券为已使用，这样用户就不能再使用这个优惠券了，同时我们也可以关联查询到优惠券的使用量让运营同学进行分析。

了解领取优惠券的具体实现之后，后面的开发就简单了，这里就不再细说了，属于是商业机密了（其实就是代码写的太烂）。

优惠券到底带来了什么

优惠券的技术方案完成后，我们就应该深思一下，优惠券对我们来说到底有什么用，可以给我们带来什么好处？

对于用户而言自然是比之前便宜了许多，更省钱；用户觉得自己赚了，性价比高。

对于运营而言，可以对运营效果进行评估，比如销售变化、客户流失、获客成本等进而调整后续的营销活动；查看不同营销渠道表现，确定不同营销渠道优惠券效果；还可以利用历史数据预测未来的销售趋势，就像我们国庆节的优惠券就是参考了去年的优惠券使用情况来定的。

这也就是为什么运营同学会对优惠券这么痴迷了。

最后

通过这个优惠券功能的开发，其实大家也发现了，从最开始的直接改价到最后的优惠券，我们要做的不光是对商品的减免，还要做运营相关的功能。所以对于开发者而言，很多功能其实不仅要关注代码怎么写，更要考虑实现这个功能的意义，如果没意义，我就不用做了（bushi）。

了解功能实现的意义之后，我们身为开发就应该本能的想到，如何确定这个功能有多少人用，如何埋点，也就是为后续的运营计划以及后续的开发计划做准备。

前言

随着物联网（IoT）技术的飞速发展中，其应用规模和使用场景正在持续扩大，但它关键的流程仍然是围绕数据传输来进行的，因此设备通信协议选择至关重要。

作为两种主要的通信协议，MQTT 协议和 HTTP 协议各自拥有独特的优势和应用场景：MQTT 完全围绕物联网设计，拥有更灵活的使用方式，和诸多专为物联网场景设计的特性；而 HTTP 的诞生比它更早，并且被广泛应用在各类非物联网应用中，用户可能拥有更加丰富的开发和使用经验。

本文将深入探讨在物联网环境下，MQTT 和 HTTP 的不同特性、应用场景以及它们在实际应用中的表现。通过对这两种协议的比较分析，我们可以更好地理解如何根据具体需求选择合适的通信协议，以优化物联网系统的性能和可靠性。

MQTT 是什么

MQTT 是一种基于发布/订阅模式的轻量级消息传输协议，针对性地解决了物联网设备网络环境复杂而不可靠、内存和闪存容量小、处理器能力有限的问题，可以用极少的代码为联网设备提供实时可靠的消息服务。

在典型的 MQTT 使用方式中，所有需要通信的客户端（通常是硬件设备和应用服务）与同一个 MQTT 服务器（MQTT Broker）建立 TCP 长连接。发送消息的客户端（发布者）与接收消息的客户端（订阅者）不需要建立直接的连接，而是通过 MQTT 服务器实现消息的路由和分发工作。

实现这一操作的关键在于另一个概念 —— **主题（Topic），**主题是 MQTT 进行消息路由的基础，它类似 URL 路径，使用斜杠 / 进行分层，比如 sensor/1/temperature。订阅者订阅感兴趣的主题，当发布者向这个主题发布消息时，消息将按照主题进行转发。

一个主题可以有多个订阅者，服务器会将该主题下的消息转发给所有订阅者；一个主题也可以有多个发布者，服务将按照消息到达的顺序转发。同一个客户端，既能作为发布者，也能作为订阅者，双方根据主题进行通信，因此 MQTT 能够实现一对一、一对多、多对一的双向通信。

HTTP 是什么

HTTP 是一种基于请求/响应模式的应用层协议，尽管它主要针对传统的客户端-服务器架构而设计，但它在物联网应用中同样扮演着重要角色。

特别说明的是，本文对比的 HTTP 特指传统的请求/响应模式用例，基于 HTTP 协议扩展实现的 WebSocket 与 Server-Sent Events 协议不参与对比。

在典型的 HTTP 使用方式中，客户端（通常是浏览器或其他网络应用）向服务器发送请求以获取资源或提交数据，服务器接收到请求后，需要处理请求并返回响应，例如将提交的数据保存到数据库中，等待另一个客户端来请求获取。

HTTP 协议使用 URL 来标识资源路径，类似于 MQTT 中的主题（Topic）。例如，HTTP 请求中的 URL 可能是 http://example.com/api/sensor，这与 MQTT 中的 sensor/1/temperature 主题有相似的分层结构。

HTTP 每次通信都通过独立的请求和响应流程完成，因此它需要额外的开销，并且两个客户端之间无法直接通信，在实时性上稍有欠缺。

资源消耗对比

MQTT 和 HTTP 都是非常简单的协议，许多物联网硬件设备和嵌入式系统都同时提供了对两者的支持。实时上资源体积与运行内存通常不会限制两者的使用，但 MQTT 设计初衷和使用特性是针对物联网设计，因此长期使用中，它具有更小的资源消耗。

首先，MQTT 在连接方面具有较低的开销。MQTT 将协议本身占用的额外消耗最小化，消息头部最小只需要占用 2 个字节，连接建立时的握手过程相对简单，可稳定运行在带宽受限的网络环境下。

一旦建立连接，客户端和服务器之间可以保持长时间的持久连接，多个消息可以在同一连接上传输，从而减少了频繁建立和断开连接的开销。以向 topic/1 主题发布 HelloWorld 内容为例，其报文信息如下：

HTTP 在每个请求-响应周期中都需要建立和断开连接，会带来额外的服务器资源使用。相对来说，HTTP 协议较为复杂，消息头部较大。同时，由于它是无状态协议，因此每次连接时客户端都需要携带额外的身份信息，这会进一步增加带宽消耗。

以向 http://localhost:3000/topic URL 传输 HelloWorld 内容为例，在不携带身份凭证的情况下，其报文信息如下：

总结：

• MQTT 的连接开销较低，连接建立简单，报文头较小，适用于需要频繁通信或保持持久连接的场景。


• 相比之下，HTTP 需要在每次请求-响应周期中建立和关闭连接，报文头较大，在网络带宽有限的情况下可能会增加传输延迟和负担。

在报文尺寸和连接开销方面，MQTT 通常比 HTTP 更为高效，特别是在需要频繁通信、保持长连接或网络带宽有限的物联网场景下。

安全性对比

MQTT 和 HTTP 两者都是基于 TCP 的协议，并且在协议设计上都充分考虑了安全性。

SSL/TLS 加密

两者都能支持通过 SSL/TLS 进行加密通信：

• 可以保护数据在传输过程中的机密性和完整性；


• 可以防止数据被窃听、篡改或伪造。

多样化的认证授权机制

• MQTT 提供了用户名/密码认证，可以扩展支持 JWT 认证，也支持客户端和服务器之间的 X.509 证书认证；在授权方面，可以支持基于主题的发布订阅授权检查，取决于MQTT 服务器的实现，。


• HTTP 则提供了更灵活的选项，包括基本认证（Basic Auth）、令牌认证（Token Auth）、OAuth 认证；可以通过应用层的权限控制机制，通过访问令牌（Access Token）、会话管理等来控制资源的访问权限。

物联网特性对比

MQTT 协议是专为物联网而设计的通讯协议，内置了丰富的物联网场景特性，能够有效地帮助用户实现设备间稳定可靠的通讯、实时数据传输功能，满足灵活的业务场景需求。

断线重连与持久会话

MQTT 支持持久连接和断线重连，确保设备与服务器之间的稳定通信，即使在网络不稳定的情况下也能保持连接。客户端可以选择是否创建持久会话，在断线重连时恢复之前的会话状态，确保消息不会丢失。

QoS 控制

MQTT 提供三种 QoS 等级：

• QoS 0：最多一次传递，消息可能会丢失。


• QoS 1：至少一次传递，消息可能重复。


• QoS 2：只有一次传递，消息保证不丢失也不重复。

客户端可根据需求选择适当的 QoS 等级，确保消息传递的可靠性。

共享订阅

多个客户端可以订阅相同的主题，接收相同的消息，适用于多个设备间共享数据或订阅相同事件的场景。

保留消息

服务器可以保留指定主题最新的消息，当新的订阅者连接时立即发送，确保新订阅者获取最新数据。

遗嘱消息

客户端可以设置遗嘱消息，当客户端异常断开连接时，服务器会发布遗嘱消息，通知其他订阅者客户端已离线。

消息过期间隔

可以设置消息的过期时间，确保消息在一定时间内被消费，避免过期消息对系统造成不必要的负担。

尽管 HTTP 是 Web 应用中使用最广泛的协议之一，基于成熟的工具链和功能设计经验用户可以实现一些特性，但需要额外的开发工作。在物联网场景下，由于 MQTT 协议原生内置了许多适用于物联网的特性，使用 MQTT 可以降低开发成本，提高通信效率，更适合于物联网应用的需求。

对比总结

总而言之，MQTT 和 HTTP 在通信模型和物联网特性上有显著的区别：

• MQTT 基于发布订阅模型，HTTP 基于请求响应，因此 MQTT 支持双工通信。


• MQTT 可实时推送消息，但 HTTP 需要通过轮询获取数据更新。


• MQTT 是有状态的，但是 HTTP 是无状态的。


• MQTT 可从连接异常断开中恢复，HTTP 无法实现此目标。


• MQTT 支持更多开箱即用的物联网功能，HTTP 则没有针对性的设计。

这些差异将直接影响它们物联网中的使用场景选择：

• 实时通信： MQTT 在实时性要求较高的场景下更为适用。由于其基于发布/订阅模型，设备可以实时推送消息给服务器或其他设备，而不需要等待请求。例如，实时监测传感器数据、实时控制设备等场景下，MQTT 可以提供更快的响应速度。


• 轻量且频繁的通信： 对于带宽和资源有限的环境，MQTT 通常比 HTTP 更加高效。MQTT 不需要频繁建立连接，且消息头相对较小，通信开销较低；而 HTTP 同步的请求/响应模式则显得效率低下，每次通信都需要完整的请求和响应头，导致带宽和资源的浪费。


• 网络波动的场景： MQTT 支持客户端与服务器之间的持久连接，并且能够从连接异常中恢复，这意味着即使网络断开，设备重新连接后也能够恢复通信。而 HTTP 是无状态的，每次通信都是独立的，无法实现断线恢复。

另一个想法：MQTT 与 HTTP 集成使用

到目前为止，我们讨论的都是在物联网设备上更应该选择哪个协议的问题。实际上，在一个复杂的物联网应用中，不仅有硬件设备，还涉及到其他客户端角色和业务流程。MQTT 和 HTTP 作为物联网和互联网中最广泛使用的两种协议，在许多场景下可以互相补充使用，提高系统的效率和灵活性。

例如，在一个典型的车联网应用中，用户侧更适合使用 HTTP 协议：用户可以通过 App 中的"打开车门"按钮来控制停在车库中的汽车。这个过程中，App 与服务器之间并不是双向通信，使用 HTTP 也能实现更复杂和灵活的安全与权限检查。而服务器到车辆之间则依赖实时的双向通信：车辆需要确保任何时候都能够响应来自用户的操作。

车辆可以通过 MQTT 协议周期性的上报自身状态，服务器将其保存下来，当用户需要获取时，在 App 上通过 HTTP 协议完成请求即可。

在知名的 MQTT 服务器 EMQX 中，可以轻松、灵活地实现 MQTT 协议和 HTTP 协议的集成，从而实现这一过程。

EMQX 是一款大规模分布式 MQTT 物联网接入平台，为高可靠、高性能的物联网实时数据移动、处理和集成提供动力，助力企业快速构建物联网时代的关键应用。

HTTP → MQTT：

应用系统通过调用 EMQX 提供的 API，将 HTTP 请求转换为 MQTT 消息发送到指定设备，实现应用系统向设备发送控制指令或通知。

curl -X POST 'http://localhost:18083/api/v5/publish' \

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

  -u '<appkey>:<secret>'

  -d '{

  "payload_encoding": "plain",

  "topic": "cmd/{CAR_TYPE}/{VIN}",

  "qos": 1,

  "payload": "{ \"oper\": \"unlock\" }",

  "retain": false

}'

MQTT → HTTP：

当设备发送 MQTT 消息到 EMQX 时，通过 EMQX 提供的 Webhook 可以将消息转发到 HTTP 服务器，实现设备数据的即时传输到应用系统。

配置界面如下：

在未来版本中，EMQX 还将提供提供扩展功能，能够将实时的 MQTT 消息保存到内置的消息队列（Message Queue）和流（Stream）中，并允许用户通过 HTTP 拉取的方式进行消费，更好地支持复杂的物联网应用场景，提供更强大的消息处理能力。

总结

总的来说，选择 MQTT 还是 HTTP 取决于具体的应用需求和场景特点。如果需要实时性好、双向通信、资源占用低的通信方式，可以选择 MQTT；只有简单的请求/响应通信，例如物联网客户端数据采集上报、主动拉取服务器数据，或者迫切希望使用现有的 Web 基础设施，那么可以选择 HTTP。

刚毕业时候年轻气盛，和邻居组的老板吵了几句。后来我晋升时，发现他是评委…… 曾经的我多么嚣张，现在的我就多么低调。

一路走来，磕磕绊绊，几年来，我总结了工作上的思考……

工作思考

代码编写和技术问题

当你写下一行代码前

当你设计一个接口时

起因

最近公司事情不是太多，我趁着这段时间在网上学习一些Cool~的效果。今天我想和大家分享一个故障时钟的效果。很多时候，一个效果开始看起来很难，但是当你一步步摸索之后，就会发现其实它们只是由一些简单的效果组合而成的。

什么是故障效果(Glitch)

"glitch" 效果是一种模拟数字图像或视频信号中出现的失真、干扰或故障的视觉效果。它通常表现为图像的一部分或整体闪烁、抖动、扭曲、重叠或变形。这种效果常常被用来传达技术故障、数字崩溃、未来主义、复古风格等主题，也经常在艺术作品、音乐视频、电影、广告和网页设计中使用。Glitch 效果通常通过调整图像、视频或音频的编码、解码或播放过程中的参数来实现。 来自ChatGPT

可以看到关键的表现为一部分或整体闪烁、抖动、扭曲、重叠或变形，所以我们应该重点关注用CSS实现整体闪烁、抖动、扭曲、重叠或变形

CSS 实现闪烁

Glitch 闪烁通常是指图像或视频中出现的突然的、不规则的、瞬间的明暗变化或闪烁效果

那么我们有没有办法通过CSS来实现上述的效果，答案是通过随机不规则的clip-path来实现！

我们先来看看clip-path的定义与用法

clip-path CSS 属性使用裁剪方式创建元素的可显示区域。区域内的部分显示，区域外的隐藏。

/* <basic-shape> values */

clip-path: inset(100px 50px);

clip-path: circle(50px at 0 100px);

clip-path: ellipse(50px 60px at 0 10% 20%);

clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);

clip-path: path(

  "M0.5,1 C0.5,1,0,0.7,0,0.3 A0.25,0.25,1,1,1,0.5,0.3 A0.25,0.25,1,1,1,1,0.3 C1,0.7,0.5,1,0.5,1 Z"

);

再想想所谓的Glitch故障闪烁时的效果是不是就是部分画面被切掉了~

span {  

    display: block;  

    position: relative;  

    font-size: 128px;  

    line-height: 1;  

    animation: clock 1s infinite linear alternate-reverse;  

}



@keyframes clock {  

0%{  

    clip-path: inset(0px 0px calc(100% - 10px) 0);  

}  

100%{  

    clip-path: inset(calc(100% - 10px) 0px 0px 0);  

}  

}

此时的效果如下:

啥啥啥，这看着是什么呀根本不像闪烁效果嘛，先别急，想想我们闪烁效果的定义突然的、不规则的、瞬间的明暗变化,此时因为我们是在切割整体元素，如果我们再后面再重叠一个正常元素！

span {  



    display: block;  

    position: relative;  

    font-size: 128px;  

    line-height: 1;  

    //animation: clock 1s infinite linear alternate-reverse;  

  

    &:before{  

        display: block;  

        content: attr(data-time);  

        position: absolute;  

        top: 0;  

        color: $txt-color;  

        background: $bg-color;  

        overflow: hidden;  

        width: 720px;  

        height: 128px;  

    }  

  

    &:before {  

        left: -2px;  

        animation: c2 1s infinite linear alternate-reverse;  

    }  

  

}



@keyframes c2 {  

    0%{  

        clip-path: inset(0px 0px calc(100% - 10px) 0);  

    }  

    100%{  

        clip-path: inset(calc(100% - 10px) 0px 0px 0);  

    }  

}

可以看到通过手动偏移了-2px后然后不断剪裁元素已经有了一定的闪烁效果，但是目前的闪烁效果过于呆滞死板，我们通过scss的随机函数优化一下效果。

@keyframes c2 {  

    @for $i from 0 through 20 {  

        #{percentage($i / 20)} {  

            $y1: random(100);  

            $y2: random(100);  

            clip-path: polygon(0% $y1 * 1px, 100% $y1 * 1px, 100% $y2 * 1px, 0% $y2 * 1px); 

        }  

    }  

    23% {  

        transform: scaleX(0.8);  

    }  

}

此时效果如下

可以看到闪烁的效果已经很强烈了,我们依葫芦画瓢再叠加一个元素上去使得故障效果再强烈一些。

span {  

    display: block;  

    position: relative;  

    font-size: 128px;  

    line-height: 1;  



    &:before,  

    &:after {  

        display: block;  

        content: attr(data-time);  

        position: absolute;  

        top: 0;  

        color: $txt-color;  

        background: $bg-color;  

        overflow: hidden;  

        width: 720px;  

        height: 128px;  

    }  



    &:before {  

        left: calc(-#{$offset-c2});  

        text-shadow: #{$lay-c2} 0 #{$color-c2};  

        animation: c2 1s infinite linear alternate-reverse;  

    }  



    &:after {  

        left: #{$offset-c1};  

        text-shadow: calc(-#{$lay-c1}) 0 #{$color-c1};  

        animation: c1 2s infinite linear alternate-reverse;  

    }  

}

此时我们已经通过:before和:after叠加了相同的元素并且一个设置蓝色一个设置红色，让故障效果更真实！

CSS 实现扭曲效果

上述的效果已经非常贴近我们传统意义上理解的Glitch效果了，但是还差了一点就是通常表现为图像的一部分或整体闪烁、抖动、扭曲、重叠或变形中的扭曲和变形,碰巧的是CSS实现这个效果非常容易，来看看~

skewX()  函数定义了一个转换，该转换将元素倾斜到二维平面上的水平方向。它的结果是一个<transform-function>数据类型。

Cool~最后一块拼图也被补上了~~

@keyframes is-off {  

    0%, 50%, 80%, 85% {  

        opacity: 1;  

    }  

    56%, 57%, 81%, 84% {  

        opacity: 0;  

    }  

    58% {  

        opacity: 1;  

    }  

    71%, 73% {  

        transform: scaleY(1) skewX(0deg);  

    }  

    72% {  

        transform: scaleY(3) skewX(-60deg);  

    }  

    91%, 93% {  

        transform: scaleX(1) scaleY(1) skewX(0deg);  

        color: $txt-color;  

    }  

    92% {  

        transform: scaleX(1.5) scaleY(0.2) skewX(80deg);  

        color: green;  

    }  

}

来看看完整的效果和代码吧！

结语

春风若有怜花意，可否许我再少年。

感谢
Glitch Clock

一、微信内部点击链接

微信公众号主页链接：

https://mp.weixin.qq.com/mp/profile_ext?action=home&__biz=XXX#wechat_redirect

1.1 action

action 代表当前路径前端框架的哪个页面

• home：当前路径前端框架首页

1.2 __biz

__biz 代表微信公众号 ID

1.2.1 __biz 的获取方式

1. 在网页中打开该公众号的任意一篇推文 ➡️ 右击鼠标选择检查 ➡️ 在元素下搜素__biz
    

org:url 表示当前内容链接

2. 从公众平台进入公众号 ➡️ 公众号设置页，右键打开检查 ➡️ 搜索 uin_base64

二、微信外部点击链接

目前微信官方没有提供相应的功能，但是有的第三方平台可以实现，比如天天外链

但是需要注意，配置的网页地址不能是公众号首页或关注页，必须是永久公众号文章链接。

作者：南殇
来源：juejin.cn/post/7216518492613656636

一直幻想着能够成为一个海王，于是做了一个微信自动聊天的工具。

测试微信版本：wechat 3.9.12.17

采用技术：

• Bmob后端云（AI对话和存储需要自动聊天的人和prompt）


• uiautomation


• pyautogui

开发语言：

• python，conda环境下运行

最终的效果大家可以看B站：http://www.bilibili.com/video/BV1yK…

一、获取微信对话内容

这里采用了网上的一些开源项目进行修改，写了一个自己的WeChat控制类，采用的是uiautomation和pyautogui组件进行UI的控制，模拟人的操作。

WeChat控制类的内容比较多，为了方便阅读，这里只呈现一部分，有需要的朋友可以联系我获取。

class WeChat:

    def __init__(self, path, locale="zh-CN"):

        # 微信打开路径

        self.path = path



        # 用于复制内容到剪切板

        self.app = QApplication([])



        self.lc = WeChatLocale(locale)



    # 鼠标移动到控件上

    def move(self,element):

        x, y = element.GetPosition()

        auto.SetCursorPos(x, y)



    # 鼠标快速点击控件

    def click(self,element):

        x, y = element.GetPosition()

        auto.Click(x, y)



    # 鼠标右键点击控件

    def right_click(self,element):

        x, y = element.GetPosition()

        auto.RightClick(x, y)





    # 鼠标快速点击两下控件

    def double_click(self,element):

        x, y = element.GetPosition()

        auto.SetCursorPos(x, y)

        element.DoubleClick()





    # 打开微信客户端

    def open_wechat(self):

        subprocess.Popen(self.path)



    # 搜寻微信客户端控件

    def get_wechat(self):

        return auto.WindowControl(Depth=1, Name=self.lc.weixin)



    # 防止微信长时间挂机导致掉线

    def prevent_offline(self):

        self.open_wechat()

        self.get_wechat()



        search_box = auto.EditControl(Depth=8, Name=self.lc.search)

        self.click(search_box)



    # 搜索指定用户

    def get_contact(self, name):

        self.open_wechat()

        self.get_wechat()



        search_box = auto.EditControl(Depth=8, Name=self.lc.search)

        self.click(search_box)



        pyperclip.copy(name)

        auto.SendKeys("{Ctrl}v")



        # 等待客户端搜索联系人

        time.sleep(0.3)

        search_box.SendKeys("{enter}")



    # 鼠标移动到发送按钮处点击发送消息

    def press_enter(self):

        # 获取发送按钮

        send_button = auto.ButtonControl(Depth=15, Name=self.lc.send)

        self.click(send_button)

        

    # 检测微信发新消息的用户

    def check_new_user(self):

        self.open_wechat()

        self.get_wechat()



        users = []



        # 获取左侧聊天按钮

        chat_btn = auto.ButtonControl(Name=self.lc.chats)

        self.double_click(chat_btn)



        # 持续点击聊天按钮，直到获取完全部新消息

        item = auto.ListItemControl(Depth=10)

        prev_name = item.ButtonControl().Name

        while True:

            # 判断该联系人是否有新消息

            pane_control = item.PaneControl()

            if len(pane_control.GetChildren()) == 3:

                users.append(item.ButtonControl().Name)



            self.click(item)



            # 跳转到下一个新消息

            self.double_click(chat_btn)

            item = auto.ListItemControl(Depth=10)



            # 已经完成遍历，退出循环

            if prev_name == item.ButtonControl().Name:

                break



            prev_name = item.ButtonControl().Name



        return users

二、获取需要自动聊天的人和对应的prompt

这部分信息我存储在Bmob后端云上面，对应的表结构（表名为：autochat，创建的字段为：name、prompt）和测试的内容如下：

获取信息的时候，我采用了子线程的方式，每隔300秒获取一次新的需要自动对话的微信和对应的prompt，代码如下：

# Bmob对象

bmob = Bmob(config['bmob_appid'], config['bmob_secret'])



# 存储从Bmob后端云获取到的自动对话的微信名和对应的prompt

name_prompts = {}



# 从Bmob后端云获取自动聊天的微信名和prompt

def get_user_prompt():

    users = bmob.findObjects('autochat')

    name_prompts.clear()

    for user in users:

        name_prompts[user.name] = user.prompt



# 每隔5分钟获取一次要自动聊天微信名称和对应的prompt

def run_with_interval():

    while True:

        get_user_prompt()

        time.sleep(300)



if __name__ == "__main__":

    t = threading.Thread(target=run_with_interval)

    t.start()

三、组装对话上下文和自动对话

这里主要用到了WeChat类的获取新对话人名字、获取某个人历史聊天记录的方法，和Bmob后端云的AI功能，具体代码如下：

# 执行自动聊天功能

def main():

    wechat = WeChat(path=config['wechat_path'])

    # 创建一个锁

    lock = threading.Lock()



    while True:

        try:

            comtypes.CoInitialize()

            # 确保微信操作的线程安全

            with lock:

                wechat.click(auto.ButtonControl(Name=wechat.lc.facorites))

                users = wechat.check_new_user()

                if len(users) <= 0:

                    time.sleep(5)

                    print("暂时没有新消息")

                    continue



                for user in users:

                    if user not in name_prompts.keys():

                        time.sleep(5)

                        print(f"{user}不在需要自动问答的名单上")

                        continue

                    else:

                        # 获取聊天记录，30这个数字可以调整，越大的话，AI会越了解你，但消耗的token也越多

                        msgList = wechat.get_dialogs(user, 30)

                        if len(msgList) <= 0:

                            continue

                        

                        # 组装上下文对话记录

                        ai = []

                        ai.append({"content": name_prompts[user], "role": "system"})

                        for msg in msgList:

                            chatmsg = msg[2].replace('[动画表情]','')

                            if chatmsg=='':

                                continue



                            if msg[1] == user:

                                ai.append({"content": chatmsg, "role": "user"})

                            else:

                                ai.append({"content": chatmsg, "role": "assistant"})



                        bmob.connectAI()

                        to = bmob.chat2(ai)

                        bmob.closeAI()

                        print('ai:'+to)



                        if to != "":

                            wechat.send_msg(user, to)

        except Exception as e:

            print(e)

import { Hono } from 'hono'

import { handle } from 'hono/vercel'



const app = new Hono().basePath('/api')



app.get('/hello', (c) => {

  return c.json({

    message: 'Hello Next.js!',

  })

})



export const GET = handle(app)

export const POST = handle(app)

export const PUT = handle(app)

export const DELETE = handle(app)

import { z } from 'zod'

import { zValidator } from '@hono/zod-validator'

import { Hono } from 'hono'



const paramSchema = z.object({

  id: z.string().cuid(),

})



const jsonSchema = z.object({

  status: z.boolean(),

})



const app = new Hono().put(

  '/users/:id',

  zValidator('param', paramSchema),

  zValidator('json', jsonSchema),

  (c) => {

    const { id } = c.req.valid('param')

    const { status } = c.req.valid('json')



    // 逻辑代码...



    return c.json({})

  },

)



export default app

   if (!result.success) {

-    return c.json(result, 400)

   }



   if (!result.success) {

+    throw result.error

   }

import { z } from 'zod'

import type { Context } from 'hono'

import { HTTPException } from 'hono/http-exception'



export function handleError(err: Error, c: Context): Response {

  if (err instanceof z.ZodError) {

    const firstError = err.errors[0]



    return c.json(

      { code: 422, message: `\`${firstError.path}\`: ${firstError.message}` },

      422,

    )

  }



  // handle other error, e.g. ApiError



  return c.json(

    {

      code: 500,

      message: '出了点问题, 请稍后再试。',

    },

    { status: 500 },

  )

}

3. 在 server/api/index.ts ，也就是 hono app 对象中绑定错误捕获。

const app = new Hono().basePath('/api')



app.onError(handleError)

4. 更改 zValidator 导入路径。

- import { zValidator } from '@hono/zod-validator'



+ import { zValidator } from '@/server/api/validator'

这样就将错误统一处理，且后续自定义业务错误也同样如此。

:::note 顺带一提

如果需要让 zod 支持中文错误提示，可以使用 zod-i18n-map

:::

RPC

Hono 有个特性我很喜欢也很好用，可以像 TRPC 那样，导出一个 client 供前端直接调用，省去编写前端 api 调用代码以及对应的类型。

这里我不想在过多叙述 RPC(可见我之前所写有关 TRPC 的使用)，直接来说说有哪些注意点。

链式调用

还是以 User CRUD 的代码为例，不难发现 .get .post .put 都是以链式调用的写法来写的，一旦拆分后，此时接口还是能够调用，但这将会丢失此时路由对应的类型，导致 client 无法使用获取正常类型，使用链式调用的 app 实例化对象则正常。

替换原生 Fetch 库

hono 自带的 fetch 或者说原生的 fetch 非常难用，为了针对业务错误统一处理，因此需要选用请求库来替换，这里我的选择是 ky，因为他的写法相对原生 fetch 更友好一些，并且不会破坏 hono 原有类型推导。

在 lib/api-client.ts 编写以下代码

import { AppType } from '@/server/api'

import { hc } from 'hono/client'

import ky from 'ky'



const baseUrl =

  process.env.NODE_ENV === 'development'

    ? 'http://localhost:3000'

    : process.env.NEXT_PUBLIC_APP_URL!



export const fetch = ky.extend({

  hooks: {

    afterResponse: [

      async (_, __, response: Response) => {

        if (response.ok) {

          return response

        } else {

          throw await response.json()

        }

      },

    ],

  },

})



export const client = hc<AppType>(baseUrl, {

  fetch: fetch,

})

这里我是根据请求状态码来判断本次请求是否为异常，因此使用 response.ok，而响应体正好有 message 字段可直接用作 Error message 提示，这样就完成了前端请求异常处理。

至于说请求前自动添加协议头、请求后的数据转换，这就属于老生常谈的东西了，这里就不多赘述，根据实际需求编写即可。

请求体与响应体的类型推导

配合 react-query 可以更好的获取类型安全。此写法与 tRPC 十分相似，相应代码 → Inferring Types

// hooks/users/use-user-create.ts



import { client } from '@/lib/api-client'

import { InferRequestType, InferResponseType } from 'hono/client'

import { useMutation } from '@tanstack/react-query'

import { toast } from 'sonner'

const $post = client.api.users.$post



type BodyType = InferRequestType<typeof $post>['json']



type ResponseType = InferResponseType<typeof $post>['data']



export const useUserCreate = () => {

  return useMutation<ResponseType, Error, BodyType>({

    mutationKey: ['create-user'],

    mutationFn: async (json) => {

      const { data } = await (await $post({ json })).json()



      return data

    },

    onSuccess: (data) => {

      toast.success('User created successfully')

    },

    onError: (error) => {

      toast.error(error.message)

    },

  })

}

在 app/users/page.tsx 中的使用

'use client'



import { useUserCreate } from '@/features/users/use-user-create'



export default function UsersPage() {

  const { mutate, isPending } = useUserCreate()



  const handleSubmit = (e: React.FormEvent) => {

    e.preventDefault()

    const formData = new FormData(e.currentTarget)

    const name = formData.get('name') as string

    const email = formData.get('email') as string

    mutate({ name, email })

  }



  return (

    <form onSubmit={handleSubmit}>

      <div>

        <label htmlFor='name'>Name:label>

        <input type='text' id='name' name='name' />

      div>

      <div>

        <label htmlFor='email'>Email:label>

        <input type='email' id='email' name='email' />

      div>

      <button type='submit' disabled={isPending}>

        Create User

      button>

    form>

  )

}

OpenAPI 文档

这部分我已经弃坑了，没找到一个很好的方式为 Hono 写 OpenAPI 文档。不过对于 TS 全栈开发者，似乎也没必要编写 API 文档（接口自给自足），更何况还有 RPC 这样的黑科技，不担心接口的请求参数与响应接口。

如果你真要写，那我说说几个我遇到的坑，也是我弃坑的原因。

首先就是写法上，你需要将所有的 Hono 替换成 OpenAPIHono (来自 @hono/zod-openapi， 其中 zod 实例 z 也是)。以下是官方的示例代码，我将其整合到一个文件内

import { createRoute, OpenAPIHono, z } from '@hono/zod-openapi'

import { swaggerUI } from '@hono/swagger-ui'



const app = new OpenAPIHono()



const ParamsSchema = z.object({

  id: z

    .string()

    .min(3)

    .openapi({

      param: {

        name: 'id',

        in: 'path',

      },

      example: '123',

    }),

})



const UserSchema = z

  .object({

    id: z.string().openapi({ example: '123' }),

    name: z.string().openapi({ example: 'John Doe' }),

  })

  .openapi('User')



const route = createRoute({

  method: 'get',

  path: '/api/users/{id}',

  request: {

    params: ParamsSchema,

  },

  responses: {

    200: {

      content: {

        'application/json': {

          schema: UserSchema,

        },

      },

      description: 'Retrieve the user',

    },

  },

})



app.openapi(route, async (c) => {

  const { id } = c.req.valid('param')



  // 逻辑代码...

  const user = {

    id,

    name: 'Ultra-man',

  }



  return c.json(user)

})

从上述代码的可读性来看，第一眼你很难看到清晰的看出这个接口到底是什么请求方法、请求路径，并且在写法上需要使用 .openapi 方法，传入一个由 createRoute 所创建的 router 对象。并且写法上不是在原有基础上扩展，已有的代码想要通过代码优先的方式来编写 OpenAPI 文档将要花费不小的工程，这也是我为何不推荐的原因。

定义完接口(路由)之后，只需要通过 app.doc 方法与 swaggerUI 函数，访问 /api/doc 查看 OpenAPI 的 JSON 数据，以及访问 /api/ui 查看 Swagger 界面。

import { swaggerUI } from '@hono/swagger-ui'



app.doc('/api/doc', {

  openapi: '3.0.0',

  info: {

    version: '1.0.0',

    title: 'Demo API',

  },

})



app.get('/api/ui', swaggerUI({ url: '/api/doc' }))

从目前来看，OpenAPI 文档的生成仍面临挑战。我们期待 Hono 未来能推出一个功能，可以根据 app 下的路由自动生成接口文档（相关Issue已存在）。

仓库地址

附上本文中示例 demo 仓库链接（这个项目就不搞线上访问了）

github.com/kuizuo/next…

后记

其实我还想写写 Auth、DB 这些服务集成的(这些都在我实际工作中实践并应用了)，或许是太久未写 Blog 导致手生了不少，这篇文章也是断断续续写了好几天。后续我将会出一版完整的我个人的 Nextjs 与 Hono 的最佳实践模版。

也说说我为什么会选用 Hono.js 作为后端服务, 其实就是 Next.js 的 API Route 实在是太难用了，加之轻量化，你完全可以将整个 Nextjs + Hono 服务部署在 Vercel 上，并且还能用上 Edge Functions 的特性。(就是有点小贵)

但不过从我的 Nest.js 开发经验来看（也可能是习惯了 Spring Boot 那套三层架构开发形态），总觉得 Hono 差了点意思，说不出来的体验，可能这就是所谓的全栈框架的开发感受吧。

你好，我是猿java。

线程是 Java执行的最小单元，通常意义上来说，多个线程是为了加快速度且无需保序，这篇文章，我们来分析一道农业银行的面试题目：如要保证线程T1, T2, T3顺序执行？

考察意图

在面试中出现这道问题，通常是为了考察候选人的以下几个知识点：

1. 多线程基础知识： 希望了解候选人是否熟悉Java多线程的基本概念，包括线程的创建、启动和同步机制。

2. 同步机制的理解：候选人需要展示对Java中各种同步工具的理解，如join()、CountDownLatch、Semaphore、CyclicBarrier等，并知道如何在不同场景下应用这些工具。

3. 线程间通信：希望候选人理解线程间通信的基本原理，例如如何使用wait()和notify()来协调线程。

4. 对Java并发包的熟悉程度： 希望候选人了解Java并发包（java.util.concurrent）中的工具和类，展示其对现代Java并发编程的掌握。

保证线程顺序执行的方法

在分析完面试题的考察意图之后，我们再分析如何保证线程顺序执行，这里列举了几种常见的方式。

join()

join()方法是Thread类的一部分，可以让一个线程等待另一个线程完成执行。 当你在一个线程T上调用T.join()时，调用线程将进入等待状态，直到线程T完成（即终止）。因此，可以通过在每个线程启动后调用join()来实现顺序执行。

如下示例代码，展示了join()如何保证线程顺序执行：

Thread t1 = new Thread(() -> {

   // 线程T1的任务

});



Thread t2 = new Thread(() -> {

   // 线程T2的任务

});



Thread t3 = new Thread(() -> {

   // 线程T3的任务

});



t1.start();

t1.join(); // 等待t1完成



t2.start();

t2.join(); // 等待t2完成



t3.start();

t3.join(); // 等待t3完成

CountDownLatch

CountDownLatch通过一个计数器来实现，初始时，计数器的值由构造函数设置，每次调用countDown()方法，计数器的值减1。当计数器的值变为零时，所有等待在await()方法上的线程都将被唤醒，继续执行。

CountDownLatch是Java并发包（java.util.concurrent）中的一个同步辅助类，用于协调多个线程之间的执行顺序。它允许一个或多个线程等待另外一组线程完成操作。

如下示例代码，展示了CountDownLatch如何保证线程顺序执行：

CountDownLatch latch1 = new CountDownLatch(1);

CountDownLatch latch2 = new CountDownLatch(1);



Thread t1 = new Thread(() -> {

   // 线程T1的任务

   latch1.countDown(); // 完成后递减latch1

});



Thread t2 = new Thread(() -> {

   try {

       latch1.await(); // 等待T1完成

       // 线程T2的任务

       latch2.countDown(); // 完成后递减latch2

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



Thread t3 = new Thread(() -> {

   try {

       latch2.await(); // 等待T2完成

       // 线程T3的任务

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



t1.start();

t2.start();

t3.start();

CountDownLatch关键方法解析：

• CountDownLatch(int count) : 构造函数，创建一个CountDownLatch实例，计数器的初始值为count。


• void await() : 使当前线程等待，直到计数器的值变为零。


• boolean await(long timeout, TimeUnit unit) : 使当前线程等待，直到计数器的值变为零或等待时间超过指定的时间。


• void countDown() : 递减计数器的值。当计数器的值变为零时，所有等待的线程被唤醒。

Semaphore

Semaphore通过一个计数器来管理许可，计数器的初始值由构造函数指定，表示可用许可的数量。线程可以通过调用acquire()方法请求许可，如果许可可用则授予访问权限，否则线程将阻塞。使用完资源后，线程调用release()方法释放许可，从而允许其他阻塞的线程获取许可。

如下示例代码，展示了Semaphore如何保证线程顺序执行：

Semaphore semaphore1 = new Semaphore(0);

Semaphore semaphore2 = new Semaphore(0);



Thread t1 = new Thread(() -> {

   // 线程T1的任务

   semaphore1.release(); // 释放一个许可

});



Thread t2 = new Thread(() -> {

   try {

       semaphore1.acquire(); // 获取许可，等待T1完成

       // 线程T2的任务

       semaphore2.release(); // 释放一个许可

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



Thread t3 = new Thread(() -> {

   try {

       semaphore2.acquire(); // 获取许可，等待T2完成

       // 线程T3的任务

   } catch (InterruptedException e) {

       Thread.currentThread().interrupt();

   }

});



t1.start();

t2.start();

t3.start();

Semaphore关键方法分析：

• Semaphore(int permits) ：构造一个具有给定许可数的Semaphore。


• Semaphore(int permits, boolean fair) ：构造一个具有给定许可数的Semaphore，并指定是否是公平的。公平性指的是线程获取许可的顺序是否是先到先得。


• void acquire() ：获取一个许可，如果没有可用许可，则阻塞直到有许可可用。


• void acquire(int permits) ：获取指定数量的许可。


• void release() ：释放一个许可。


• void release(int permits) ：释放指定数量的许可。


• int availablePermits() ：返回当前可用的许可数量。


• boolean tryAcquire() ：尝试获取一个许可，立即返回true或false。


• boolean tryAcquire(long timeout, TimeUnit unit) ：在给定的时间内尝试获取一个许可。

单线程池

单线程池（Executors.newSingleThreadExecutor()）可以确保任务按提交顺序依次执行。所有任务都会在同一个线程中运行，保证了顺序性。

如下示例代码展示了单线程池如何保证线程顺序执行：

ExecutorService executor = Executors.newSingleThreadExecutor();

executor.submit(new T1());

executor.submit(new T2());

executor.submit(new T3());

executor.shutdown();

单线程这种方法简单易用，适合需要顺序执行的场景。

synchronized

synchronized 是Java中的一个关键字，用于实现线程同步，确保多个线程对共享资源的访问是互斥的。它通过锁机制来保证同一时刻只有一个线程可以执行被Synchronized保护的代码块，从而避免数据不一致和线程安全问题。

如下示例代码，展示了synchronized如何保证线程顺序执行：

class Task {

    synchronized void executeTask(String taskName) {

        System.out.println(taskName + " 执行");

    }

}



public class Main {

    public static void main(String[] args) {

        Task task = new Task();

        new Thread(() -> task.executeTask("T1")).start();

        new Thread(() -> task.executeTask("T2")).start();

        new Thread(() -> task.executeTask("T3")).start();

    }

}