专治各类疑难杂症¶

Gitea 提示“找不到对应签名的密钥”¶

仅仅将 SSH 密钥添加到 Gitea 还不够，为了防止他人伪造你的公钥，Gitea 要求你手动验证该密钥的所有权。

在你的 SSH / GPG 密钥列表中，找到刚添加的密钥，点击旁边的验证按钮。

Gitea 会弹出一个带有随机 Token 的提示框，并要求你执行一条类似如下的命令：

echo -n 'gitea-xxxxxxxxxx' | ssh-keygen -Y sign -n gitea -f /path_to_your_privkey

Windows 11 用户避坑警告

千万不要在 Windows 默认的 CMD 或 PowerShell 中执行这段命令！

Windows 的 echo 命令不支持 -n 参数，它会把 -n 甚至回车换行符一起发送给硬件密钥进行签名。这会导致生成的签名数据完全错乱，提交到 Gitea 时会永远报错“签名不匹配”。

正确操作是在 Windows 11 中打开 Git Bash。

复制 Gitea 提供的命令并在 Git Bash 中执行。将 /path_to_your_privkey 替换为你本地密钥路径。(如果读取私钥存根失败，对于硬件密钥也可以尝试指向公钥)

终端会输出一段被 -----BEGIN SSH SIGNATURE----- 和 -----END SSH SIGNATURE----- 包裹的签名块。

将这整段签名块复制，粘贴回 Gitea 的网页验证框中，点击确认即可。

Material for MkDocs 粗体无法正常渲染¶

在 Material for MkDocs 中，出现粗体无法正常渲染的问题，通常是因为 Markdown 解析器依赖空格或特定的英文单词边界来识别强调语法的起止。

当 ** 直接与中文字符紧凑相连，或紧贴括号、冒号等标点符号时，解析器会将其误认为是一段普通文本的内部字符，从而放弃渲染。

针对这个问题，可通过开启并配置 betterem 扩展解决。

打开项目的 mkdocs.yml 配置文件，找到 markdown_extensions 节点，添加 pymdownx.betterem 并开启全量智能匹配。

mkdocs.yml

markdown_extensions:
  - pymdownx.betterem:
      smart_enable: all

配置保存后，MkDocs 重新构建，绝大部分中文字母混排和括号内的加粗问题都会自动恢复正常。

如果上述方案不能解决问题，可能是 smart_enable: all 弄巧成拙。在 betterem 扩展的设计中，“智能(Smart)”这个词的实际含义是：“忽略词内强调(mid-word emphasis)”，即强制要求强调符号 ** 前后必须有英文空格或单词边界。由于中文汉字之间没有空格，在解析器看来，整句中文是一个连贯的“长单词”。如果设置了 smart_enable: all，解析器会把 ** 也变成“智能”模式，认为它插在“词内”，从而彻底拒绝渲染相连的中文加粗。

解决方案是将 ** 恢复为“非智能（允许词内强调）”模式。关闭全量智能模式，只保留对下划线 _ 的智能限制（这是官方默认且最适合中文混合排版的设置）。

mkdocs.yml

markdown_extensions:
  - pymdownx.betterem:
      smart_enable: '_'

Git 覆盖本地修改¶

注意！

以下命令将使你放弃所有本地更改，而使用远程分支中的副本重置/覆盖所有内容。

输入以下命令来覆盖本地文件：

git fetch --all
git reset --hard <remote>/<branch_name>

例如：

git fetch --all
git reset --hard origin/main

Info

不论是否使用 --hard 选项，所有尚未推送的本地提交都将丢失。

命令详解¶

git fetch 从远程下载最新版本，不会尝试合并或重新设置任何内容。

然后 git reset 将 main 分支重置为你刚获取的分支。--hard 选项更改工作树中的所有文件，以匹配 origin/main 中的文件。

擦除 ESP32-S3 固件¶

下载并安装 esptool

令 ESP32-S3 进入 DFU 模式:

按住板子上的 BOOT 按钮不放，将设备接入电脑
再单击一下 RESET 按钮
松开 BOOT 按钮
此时电脑会重新识别到一个串口设备
转至设备管理器
确定 ESP32-S3 设备所对应的串口

用命令行工具 esptool 擦除 ESP32-S3 固件，在终端中执行以下命令:

D:\esptool-v5.2.0-windows-amd64\esptool.exe --chip esp32s3 --port [ESP32-S3 设备所对应的串口 e.g.:COM3] erase_flash

显示 Flash memory erased successfully 后，你就可以像对待一块全新的 ESP32-S3 一样，用常规方法刷写任何其他固件了。

Docker Compose 限制容器的资源使用¶

运用 compose 组件可限制容器的资源使用，以下是示例:

docker-compose.yml

services:
  <service_name>:
    image: <image_path>
    # 可用的 CPU 数
    cpus: 1
    # 内存大小限制
    mem_limit: 1G

在以上示例中，容器的 CPU 使用数限制在1个，内存使用限制在1G。

参考¶

如何在 docker compose file 中限制系統資源的使用 - Zen's Blog

Define services in Docker Compose - Docker Docs

为 Proxmox 的 Windows 虚拟机安装 VirtIO 驱动¶

镜像链接: Index of /groups/virt/virtio-win/direct-downloads/archive-virtio

(2026年3月23日)目前推荐下载版本 virtio-win-0.1.271-1，更新或过旧的版本都出现了兼容性问题。

下载与挂载镜像¶

Proxmox 控制面板 - 存储 - (任意一个存储池) - ISO 镜像 - 从 URL 下载
虚拟机 - (Windows 虚拟机) - 硬件 - 添加 - CD/DVD驱动器
- 总线/设备: SCSI
- 使用 CD/DVD 光盘镜像文件（ISO）
  - 存储: (存放镜像的存储池)
  - ISO 镜像: virtio-win-0.1.271.iso

安装 VirtIO 驱动¶

打开 Windows 资源管理器，然后转至 CD-ROM 驱动器。
双击打开 virtio-win-gt-x64/x86.msi，并按照其指示操作。
双击打开 virtio-win-guest-tools.exe 安装 QEMU Guest Agent。
重启虚拟机。

或者: 手动安装所需驱动

启用 QEMU Guest Agent¶

虚拟机 - (Windows 虚拟机) - 选项 - QEMU Guest Agent
使用 QEMU Guest Agent/在备份时冻结/解冻来宾文件系统以实现一致性: True
Type: 默认 (VirtIO)

参考¶

Windows VirtIO Drivers - Proxmox VE

将已经失效的 Onedrive 账户从资源管理器边侧栏去除¶

按住 Win+R 然后输入 regedit ，然后点击 OK。
导航到 HKEY_CLASSES_ROOT > CLSID。在这个文件夹内，请按住 Ctrl+F 搜索 OneDrive. 如图所示：
请逐个搜索，直到找到一个含有 OneDrive - Personal 或 OneDrive - <CompanyName> (链接到您的 OneDrive for Business 帐户) 作为默认值的条目，类似于以下屏幕截图：
将 System.IsPinnedToNameSpaceTree 值修改为 0 > 确定。
最后，重启你的电脑。

macOS Tahoe 26.4 git 提交时调用 ed25519-sk SSH 密钥错误¶

环境¶

macOS Tahoe 26.4
Visual Studio Code 1.113.0

报错¶

Output

> git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -
error: Signing file /var/folders/71/0cg33245411cnc0d7zfrkgqm0000gn/T//.git_signing_buffer_tmpLjPKBL
Confirm user presence for key ED25519-SK SHA256:11zuoQXlgOuWaSqwMjnI0RJvlDEj+ZdgnlKZd8xJNC0
No FIDO SecurityKeyProvider specified?
Couldn't sign message: invalid format?
Signing /var/folders/71/0cg33245411cnc0d7zfrkgqm0000gn/T//.git_signing_buffer_tmpLjPKBL failed: invalid format?

fatal: failed to write commit object

解决办法(其实没解决)¶

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew uninstall --force openssh libfido2

brew install openssh libfido2

brew list libfido2

# FIDO 驱动文件: /opt/homebrew/Cellar/libfido2/1.16.0_1/lib/libfido2.1.16.0.dylib

# 重新生成密钥 该密钥不会存储在 YubiKey 设备本身
/opt/homebrew/bin/ssh-keygen -t ed25519-sk -f ~/.ssh/git-signing-for-mac

git config --global gpg.ssh.program "/opt/homebrew/bin/ssh-keygen"
git config --global gpg.ssh.ssh-keygen-extra-args "-P /opt/homebrew/Cellar/libfido2/1.16.0_1/lib/libfido2.1.16.0.dylib" # 此处需指向 FIDO 驱动文件
git config --global user.signingkey "~/.ssh/git-signing-for-mac.pub" # 新生成的公钥记得在 GitHub 注册

code Documents/Code/VSCODE.code-workspace # 通过终端启动 Visual Studio Code

不解之谜¶

按照 Gemini 的分析，报错的根源已经超出了 macOS 和 Git 的范畴，这是 PicoKey 固件（针对 RP2350 芯片）在生成底层密码学签名时的一个 Bug。OpenSSH 的安全校验极其严苛（通常基于 OpenSSL 库）。如果 PicoKey 发回的签名在长度、字节对齐或格式规范上哪怕有 1 bit 不符合严格的 FIDO2 SSH 规范，OpenSSH 就会拒绝解析这串数据，直接抛出 invalid format?（格式无效），以防范中间人攻击。

但是上述问题在 Windows 端并未出现，所以到底是哪个环节出了问题？犹未可知。

macOS Tahoe 26.4 挂载网络存储¶

创建挂载文件夹。

sudo mkdir -p /System/Volumes/Data/mnt/<volume-name>

修改挂载配置文件。

sudo nano /etc/auto_master

/etc/auto_master

/System/Volumes/Data/mnt/<volume-name> auto_mount_config -nosuid,noowners

配置对应挂载点的配置。

sudo nano /etc/auto_mount_config

/etc/auto_mount_config

<folder-name> -fstype=smbfs,soft,nobrowse ://username:password@ip/folder-name

Media -fstype=smbfs,soft,nobrowse ://cattom:password@192.168.1.7/Media

密码需 URL 编码

举例:

密码为 A#QJAY$yMY%@K0En ，经过编码后的密码为 A%23QJAY%24yMY%25%40K0En

最后，刷新挂载配置。

sudo automount -vc