如果界面所指定的字体在用户系统上未安装，则会自动降级到系统默认字体，这样会导致界面显示异常或达不到预期效果。 对于特殊字体我们通常会集成到软件安装包内，但对于汉字这样的语言，它的文字比较多，因此字体文件比较大，如果集成到安装包内会导致安装包体积变大，所以对于类似中文这样字符比较多的语言字体，我们通常会选择系统自带的字体。 而不同操作系统（如Windows和macOS）所自带的字体不一样，甚至同一操作系统不同的版本（如Windows 7和Windows 11）自带的字体也不一样，因此在选择采用什么字体前，需要弄清我们应用程序支持的操作系统所自带的字体都有哪些，才能更好的做选择。 操作系统的新版本通常只会新增字体，不会移除老的字体。

1. 背景在项目开发中时常会遇到需要多个进程间交互/通信的场景，进程间通信（IPC）的方式有很多，比如文件、注册表、网络、管道、共享内存等。 对于简单的交互场景，我们可以随意选择一种合适的方式，如 Google Chrome 使用的是管道的方式。 但在交互场景复杂的情况下，远程过程调用（RPC）的方式则会更新便捷。 目前开源的、功能相对完善的 C++ RPC 框架都是基于网络方式实现的，这种方式存在服务端和客户端的概念，两端相互调用需要各方都启动一个端口监听服务，既然需要监听端口，那就会存在端口被占用的问题，特别是在 Windows 上还会存在端口假可用的问题，端口虽然监听成功，但客户端仍然无法连接的情况。 我一直想找到一个基于共享内存实现的、跨平台的 C++ RPC 框架，但遗憾的是一直没能结缘，于是我决定烹饪一个。

本文主要介绍如何在 Node-API 中实现不同的类型的接口，如： 同步调用 基于 Napi::AsyncWorker 的异步调用，通过回调函数返回 异步调用，返回 Promise 基于 Napi::ThreadSafeFunction 的异步调用，通过回调函数返回

ABI 是 Application Binary Interface 的缩写，当我们以二进制形式（非源码形式）发布我们的动态库时，就需要关心ABI兼容（也称二进制兼容）。 对于静态库，更新静态库始终都需要该库的使用方重新编译，因此不存在ABI兼容的说法。

在使用Electron开发客户端时，如果现有Node模块所提供的功能无法满足需求，我们可以使用C++开发自定义的Node模块，也称插件（addon）。 Node.js插件的扩展名为.node，是二进制文件，其本质上是动态链接库重命名而来，在Windows平台是.dll文件，Linux/Unix平台是.so文件。

写在前面已经有了那么多的 Electron 项目模板，为什么还要再造一个？是重复造轮子吗？ 我相信大多数人选择使用 Electron 开发客户端时，或多或少都看上了 Web 开发的高效率，但Web开发人员在客户端和系统编程方面的经验相对缺乏，又加上 Electron 和前端框架（如 Vue ）结合起来也不是那么的轻而易举，开发人员大多会选择基于模板来快速上手搭建Electron项目。 目前，Electron 的模板项目已经有很多，比较流行的有electron-vite、electron-vite-vue等。在这些模板中，有的功能过于完善，代码太复杂，远远超过了很多 Electron 客户端项目本身的代码量，需要花很多时间来熟悉模板，不适合新手快速上手和修改，一旦出现问题也难以维护；有的模板又年久失修，使用的技术早已被淘汰，也不适合用来开发线上产品，而且这些模板都有一个通病，都是在用Web开发的思维来开发客户端。 基于上述原因，我开发了这个 Electron 项目模板，在开发过程中，我一直遵循稳定、易于维护的初衷。 项目地址：https://github.com/winsoft666/electron-vue3-boilerplate

写下这一行预示着2024年的工作开始了，加油！ 物来顺应，未来不迎。 当时不杂，既过不恋。

spdlog是一个高性能C++日志库，可以支持仅头文件（header-only）模式使用。 官网地址： https://github.com/gabime/spdlog spdlog是线程安全的，但不是进程安全的，可以多个线程同时使用一个spdlog对象输出日志，但不能多个进程同时往一个文件写入日志。 在spdlog内部使用fmt进行字符串的格式化，因此spdlog字符串格式的方式与fmt库相同，如： 1spdlog::critical("Support for int: {0:d}; hex: {0:x}; oct: {0:o}; bin: {0:b}", 42);