记忆转储

Logitech G502 X LIGHTSPEED 保修 RMA 全记录：滚轮故障到顺利换新

Thu, 05 Nov 2026 00:00:00 GMT

近期使用的 Logitech G502 X LIGHTSPEED 游戏鼠标遇到了滚轮机械故障问题。考虑到产品尚在保修期内，便体验了一次罗技官方的 RMA（Return Merchandise Authorization）保修申请流程。

本文整理了从发起售后、在线客服沟通、邮箱误打小插曲到最终通过审核的完整过程，供有类似保修需求的朋友参考。

1. 故障现象与保修前准备#

故障设备：Logitech G502 X LIGHTSPEED
故障现象：滚轮出现机械性失效/滚动异常，影响正常使用。
保修凭证准备：
- 购买凭证 / 发票（PDF 或清晰截图）
- 鼠标底部序列号（S/N）

Tips：建议在发起售后前，提前将发票存为 PDF 文件或准备好电子版，客服沟通中会要求上传凭证。

2. RMA 申请沟通全过程#

罗技当前的售后体验主要依靠官网的 Live Chat（在线客服） 系统。整体流程分为两个主要阶段：

阶段一：初次排查与提交申请（客服 Belle）#

故障确认：告知客服鼠标滚轮失效，按客服引导进行简单的物理确认后，客服判定硬件故障，符合保修换新条件。
提交凭证与个人信息：按要求在聊天窗口上传购买发票 PDF，并填写收货人姓名、邮编、地址、电话及联系邮箱。
工单建立：客服说明已将申请转交至高级支持部门审核，处理周期预计为 48–72 个工作小时。

阶段二：邮箱更正插曲与工单合并#

在第一次聊天结束后，发现刚才在聊天框手动敲入邮箱时少打了一个字符。为防止后续收不到发货通知，再次进入 Live Chat 进行了修正：

重新接入客服：由另一个客服接手对话。
确认系统账号信息：客服在后台核对后反馈，其实系统内部工单创建时已自动关联了登录账号的正确邮箱，手动打错并不影响后台数据。
合并工单（Merge Ticket）：为了避免多次沟通生成重复工单，客服将第二次聊天的记录合并到了最初建立的主工单编号下。

3. 结果与收尾#

提交申请后约 24 小时内，正确的邮箱便收到了官方支持团队发送的审核通过邮件：

审核结果：RMA 申请顺利通过（Approved）。
发货时间：新鼠标将在 3–4 个工作日 内由合作快递（黑猫宅急便）寄出，届时会附上物流单号。
旧设备处理：罗技官方明确无需寄回坏鼠标，只需在收到新产品确认无误后，自行按当地电子废弃物规则回收处理即可。

4. 经验总结与避坑建议#

善用发票文本：在聊天框打字填写地址和邮箱容易出现手误，可直接告知客服“以提交的发票 PDF 凭证中的个人信息为准”，更省时且零差错。
关于工单状态与调查问卷：在工单完全结案（发货完成）之前，若点击邮件里的满意度调查链接，可能会提示 The ticket is not yet solved，这是正常现象，直接忽略即可，不影响后续派送。
保持故障设备：虽然罗技通常不要求寄回坏鼠标，但在正式收到新设备前，请务必保留故障旧设备以备不时之需。

Git在push的时候防止出现Merge曲线的办法

Thu, 29 Oct 2026 00:00:00 GMT

在日常开发中，有时候会有这样一个场景：

在本地修改了几份文件并完成了 git commit，但忘记了作 git push。过了几天回到项目，你想起要推代码，于是习惯性地先执行了一句：

Terminal window

1
git pull

这时候发现远程仓库里同伴们提交了不少新代码。Git 自动帮你做了一次合并，等你在推上去（git push）之后，在 GitHub / GitLab 的网络图上就会赫然出现一条巨大的 Merge 交叉曲线。

最让人郁闷的是：你改的那几个文件，同伴根本就没动过，大家改的完全是不同的地方，本应该平滑提交的代码却留下了一个不必要的“合并节点（Merge Commit）”。

这篇文章将教你如何撤销这个 Merge 曲线，恢复成一条漂亮的直线的 Commit 历史。

为什么会出现这个 Merge 曲线？#

当你本地有尚未 Push 的 Commit，同时远程仓库又有新的 Commit 时，默认的 git pull 实际上等同于：

Terminal window

1
git fetch + git merge

Git 为了保留两边的历史记录，会主动创建一个新的 Merge Commit 把两个分支的分叉连接起来。即使两边的修改毫无冲突，这个合并节点也会被强制建立。

解决方案#

根据你是否已经将这个 Merge 曲线推送到服务器，解决办法略有区别。

场景一：只在本地 Pull 了，还没有 Push 到服务器#

这是最轻松的解决方式，只需要 “撤销合并 + 重新变基” 即可。

1. 撤销刚才的合并（回到 pull 前的状态）#

Terminal window

1
git reset --hard ORIG_HEAD

注：ORIG_HEAD 指向你执行危险操作（如 merge/pull）之前的节点。

2. 使用 `--rebase` 重新拉取#

Terminal window

1
git pull --rebase

这会把你本地未提交的改动“临时取下”，先将远程最新的代码拉下来，然后再把你的 Commit 依次“变基（Rebase）”贴在最顶部。

3. 正常推送#

Terminal window

1
git push

此时你推送到远程仓库的历史就是一条纯粹的直线，只增加了一个干净的黑点！

场景二：Merge 曲线已经 Push 到了远程服务器#

如果合并线已经提交到了服务器，想要抹掉它，就需要重写远程历史（Force Push）。

⚠️ 注意：如果这是团队多人公用的主分支（如 main / master），且别人已经基于这个 Merge 节点拉取了代码，不建议强行覆盖。如果是你自己的开发分支，可以放心操作。

1. 本地回退到 Merge 节点之前#

Terminal window

1
# 回退到上一个提交节点（即 Merge 之前的版本）
2
git reset --hard HEAD~1

2. 重新用 Rebase 方式拉取#

Terminal window

1
git pull --rebase

3. 强行推送到远程覆盖历史#

Terminal window

1
git push origin <你的分支名> --force

这样服务器上的合并曲线就会被完全抹去，历史恢复为干干净净的单条线。

常见顾虑：`git pull --rebase` 会覆盖别人的代码吗？#

绝对不会！

不管是 merge 还是 rebase，Git 的安全机制是一模一样的：

如果改动的文件没有交集，Git 会自动无缝平移你的 Commit。
如果碰巧改了同一文件的同一行，Git 会立即中断变基，提示你手动解决冲突。只有当你解决冲突并执行 git rebase --continue 后，变基才会继续进行。

一劳永逸：配置 Git 默认使用 Rebase#

为了以后不再手动输入 --rebase，也不用再担心生成难看的分叉线，建议在全局配置中开启 pull 自动 rebase：

Terminal window

1
git config --global pull.rebase true

配置完成后，以后每次使用普通的 git pull，Git 都会自动帮你的 Commit 平移到远程最新代码的头部，保持分支历史永久简洁优雅。

iCloud 自定义域名邮箱 vs 传统企业邮箱

Tue, 27 Oct 2026 00:00:00 GMT

有自己的域名的话，一般都会弄一个邮箱（例如 contact@yourdomain.com），装逼利器。

以往搭建自定义域名邮箱，第一选择通常是 Google Workspace、微软 M365 或腾讯/阿里企业邮。这几天偶然发现苹果公司也有 iCloud+ “自定义电子邮件域” 功能，所以研究了一下iCloud 的这个功能到底好不好用？

1. 原理与送达率：iCloud 是真正的邮箱还是仅仅转发？#

很多开发者和极客常用的 Cloudflare Email Routing 属于免费邮件转发（Email Forwarding），它只负责把邮件转投到你的个人邮箱，原生发信极易触发防垃圾规则。

iCloud 自定义域名邮箱：真正的托管邮箱
- 机制：MX 记录直接指向 Apple 的邮件服务器（mail.icloud.com）。
- 送达率：绑定时强制要求设置 SPF、DKIM 和 MX 记录，发信由 Apple 官方高信誉度的服务器集群代发，送达率极高，不容易进垃圾箱。
传统企业邮箱：标准的商业托管
- 机制：MX 指向各自的商业服务器（如 Google、腾讯）。
- 送达率：支持完整的 SPF、DKIM、DMARC 三大鉴权体系，在商业合规性与邮件到达率上属于行业最高标准。

2. 核心区别对比#

对比维度	iCloud+ 自定义域名邮箱	传统企业邮箱 (Google Workspace / 腾讯企业邮等)
产品定位	个人、家庭、微型工作室/独立开发者	中大型企业、正式商业公司
计费方式	订阅 iCloud+ 顺便附带 (最低 50GB 套餐即可，无需按账号额外付费)	按账号/人头收费 (例如 Google 约 $7+/人/月；腾讯专业版约 ¥200+/人/年)
邮箱账号配额	单个域名最多绑定 6 个 Apple ID（通过家人共享），每人可建 10 个前缀	无严格上限，可根据公司规模无限按需购买
存储空间	统一共享个人 iCloud 总空间 (邮件与手机备份、照片抢占 50GB/200GB/2TB)	每个账号独立空间 (如免费版每人 5G，付费商业版每人 30G/数 TB)
客户端支持	网页版、iOS/Mac 原生邮件，第三方客户端需生成“App 专用密码”配置 IMAP/SMTP	极其丰富（网页版、专属 App、标准 SMTP/IMAP、Outlook 插件等）
企业管理后台	极简（仅基础域名验证与地址分配）	强大（离职权限回收、邮件监控、组织架构树、审计日志）

3. iCloud 域名邮箱的独特优势#

极致的性价比：如果你原本就在订阅 iCloud+（哪怕是最低挡位），那么这个域名邮箱功能相当于免费赠送。无需再为个人域名邮箱每年额外掏几百块钱。
通配接收（Catch-All）：支持开启 Catch-All 功能，任何发往 任意前缀@yourdomain.com 的邮件都会自动汇总到你的主收件箱，防止遗漏重要信件。
支持跨平台使用：虽然是苹果提供的服务，但除了 iOS/Mac，你依然可以在 Windows、Android 或通过标准邮件客户端（如 Thunderbird/Outlook）使用标准 IMAP/SMTP 进行收发。

4. 传统企业邮箱不可替代的地方#

尽管 iCloud 域名邮箱性价比极高，但在以下商业场景中，你仍然需要选择传统的专业企业邮箱：

员工离职与数据安全：iCloud 域名邮箱绑定的账号属于个人 Apple ID，公司无法强制重置离职员工的密码或审计其邮件历史。
大批量邮件与营销发信：iCloud 对日发信量有一定限制，不适合用来发送大量的群发邮件或系统通知。
团队权限管理：企业邮箱提供完善的组织架构树、部门公共邮箱和邮件审批流程，这些都是 iCloud 彻底缺失的。

5. 总结与选型建议#

选择 iCloud+ 自定义域名邮箱，如果你：
- 是独立开发者、自由职业者、博主或个人创业者。
- 只需要 1~6 个人使用，想要用个性化域名打造个人品牌。
- 已经是 Apple 生态用户，追求性价比与极致的配置便利。
选择传统企业邮箱，如果你：
- 拥有正式注册的公司或扩张中的团队。
- 需要给多名员工分配独立邮箱，且需要严格的管理权限。
- 习惯使用纯粹的 Google Workspace 或国内企业微信/飞书生态。

所以感觉苹果的邮箱个人用用还是不错的，如果本身是苹果用户的话。当然免费的最香！

博客统计从不蒜子迁移到 Vercount

Mon, 26 Oct 2026 00:00:00 GMT

起因#

博客侧边栏的站点统计组件里，总访问量和访客数一直靠不蒜子提供。但它经常不稳定，页面上的数字一直卡在 ...，刷新很多次也出不来。

查了一下，不蒜子有几个已知问题：

用的人多时容易 502，速度慢
靠 Referrer 判断来源，在移动端和部分浏览器上统计不准
使用 JSONP 回调，有一定的安全隐患

Vercount 是一个不蒜子的替代方案，号称响应更快、可用性更高，兼容不蒜子的 span 标签，并且会自动从不蒜子迁移已有数据，于是决定换过去试试。

Vercount 简介#

Vercount 基于 NextJS + Redis，部署在 Vercel 上，主要特点：

响应速度快，使用全球 CDN
用 POST 请求统计，不依赖 Referrer
兼容不蒜子的 busuanzi_value_site_pv 等 id，切换成本低
支持自托管
登录并验证域名后，可以在后台编辑访问量和访客数

迁移步骤#

因为我的组件里已经用 id 加同步脚本处理好了数字的回填，所以只需要换脚本地址。

原来的代码：

1
// 加载不蒜子脚本
2
if (!document.querySelector('script[src*="busuanzi.pure.mini.js"]')) {
3
  const script = document.createElement('script');
4
  script.src = "//busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js";
5
  script.async = true;
6
  document.head.appendChild(script);
7
}

改成：

1
// 加载 Vercount 脚本
2
if (!document.querySelector('script[src*="vercount.one"]')) {
3
  const script = document.createElement('script');
4
  script.src = "https://events.vercount.one/js";
5
  script.async = true;
6
  document.head.appendChild(script);
7
}

下面的 busuanzi_value_site_pv / busuanzi_value_site_uv 隐藏元素和同步逻辑不需要改动。提交推送，博客自动编译发布即可。

遇到的问题：数字变成了 1#

发布后，页面上的访问量和访客数都变成了 1，原来的数字没有迁过来。

官方 README 说数据会自动从不蒜子迁移，但我这里没成功。我的推测是：迁移发生的那一刻，不蒜子那边的请求刚好失败了（它本来就不稳定），Vercount 就把这个域名当成新站点，从头开始计数。这只是推测，并没有官方说明。

另外要注意，Vercount 是按域名记录的。我的博客地址是 blog.jcaonet.com，主域名 jcaonet.com 做了 301 跳转到 blog。访客的浏览器不会在主域名上加载页面，所以统计数据全部挂在 blog.jcaonet.com 下面，验证和修改时都应该填这个。

先找回原来的数字#

数字存在不蒜子的服务器上，不在网站代码里。要看原来的值，得让不蒜子再显示一次：

看有没有没刷新过的旧页面，或者旧截图
把统计临时改回不蒜子（用 git revert 撤销迁移那次提交，推送发布）

Terminal window

1
git log --oneline -5      # 找到迁移那次提交的哈希
2
git revert <哈希>         # 生成撤销提交
3
git push

我回退之后，打开页面用浏览器开发者工具（F12 → Network，过滤 busuanzi）查看，发现：

busuanzi.pure.mini.js 返回 200，脚本本身加载正常
busuanzi?jsonpCallback=... 返回 502

也就是说，不蒜子服务器当时就是不可用，不是我的代码有问题。Console 里 ERR_BLOCKED_BY_CLIENT 的报错是广告拦截插件拦截了 Google Tag Manager 等脚本，和计数无关。

遇到这种情况，只能隔一段时间再刷新，等它恢复后马上记下原数字。

在 Vercount 后台修改数字#

Vercount 后台（vercount.one）登录后，进入 Domains 页面，添加域名 blog.jcaonet.com。添加后状态是 Pending verification，需要先验证域名所有权，才能使用 Edit 修改数据。

验证有两种方式：

DNS Record：到域名解析服务商添加一条 TXT 记录。页面会给出记录名（类似 _vercount.blog.jcaonet.com）和值，值要直接复制，不要手打。很多解析服务商会自动补上主域名，所以”主机记录”通常只需要填 _vercount.blog。
File Upload：按页面提示把验证文件放进项目的 public/ 目录，发布后通过网址能访问到，再点验证。对于推送后自动发布的 Astro 博客，这种方式不用动 DNS，更省事。

验证通过后，就可以用 Edit 把访问量和访客数改回原来的值。

为什么 Vercount 要验证，不蒜子不用#

不蒜子没有账号和后台，只是按域名给计数加 1，也不能修改数字，所以不需要知道域名是谁的。Vercount 有后台和修改功能，如果不验证，任何人都能注册你的域名并改你的数字，所以修改数据前必须证明域名属于你。据 README，验证是用来编辑数据的，正常计数本身不需要验证。

需要留意的点#

有人反馈过，Vercount 叠加不蒜子数据时，访问量会叠加，访客数不会，规则不一致。改完之后建议分别核对这两个数。
页面切换时（Swup）数字能否正常刷新，需要实际测试，我没有找到官方说明。
有用户提到 Vercount 会先显示缓存的旧数据，再更新成新数据，属于小缺点。

总结#

迁移本身只需要改一行脚本地址，成本很低。真正麻烦的是历史数据：自动迁移不一定成功，成功与否取决于迁移那一刻不蒜子的服务是否可用。如果你也打算迁移，建议：

迁移前先记下不蒜子当前显示的访问量和访客数
迁移后检查数字有没有被重置
如果被重置，在 Vercount 后台验证域名后手动改回去

如何安全地重命名 Git 分支（本地 + 远程）

Tue, 20 Oct 2026 00:00:00 GMT

在日常开发中，我们有时需要修改已经创建好的 Git 分支名称。
常见场景包括：修正命名错误、统一命名规范、或者在分支创建后补充更准确的描述。

本文将介绍本地 + 远程完整重命名的方法，并额外说明使用 TortoiseGit（小乌龟） 时的操作步骤。

一、核心原则#

重命名分支只是修改引用名称，不会改变任何提交历史。

分支与其他分支（例如 main / release）的祖先关系保持不变
已有的 commit 记录全部保留
不会导致历史断裂

因此可以放心操作。

二、命令行方式（推荐）#

1. 重命名本地分支#

如果当前正处于要改名的分支上：

Terminal window

1
git branch -m 新分支名

如果当前在其他分支上：

Terminal window

1
git branch -m 旧分支名 新分支名

2. 推送新分支到远程#

Terminal window

1
git push origin -u 新分支名

-u 参数会同时设置上游跟踪关系，后续可直接使用 git push / git pull。

3. 删除远程旧分支#

确认新分支已成功推送后，再删除旧分支：

Terminal window

1
git push origin --delete 旧分支名

4. 清理本地远程跟踪信息#

Terminal window

1
git fetch origin --prune

执行后，本地将不再显示已删除的远程分支。

三、TortoiseGit（小乌龟）图形化操作#

公司内如果统一使用 TortoiseGit，可按以下步骤操作：

1. 获取最新远程信息#

在仓库文件夹上右键
选择 TortoiseGit → Fetch…
勾选 Prune（清理已删除的远程分支信息）
点击 OK

2. 切换到新分支#

再次右键 → TortoiseGit → Switch/Checkout…
在 Branch 列表中选择新的分支名
点击 OK

3. 删除远程旧分支（可选）#

右键 → TortoiseGit → Browse References…
找到远程旧分支（remotes/origin/旧分支名）
右键选择 Delete

注意：删除前请确认新分支已经成功推送到远程。

四、操作时的注意事项#

先推送新分支，再删除旧分支
顺序很重要，避免中间出现“分支丢失”的情况。
分支名包含空格或特殊字符时
命令行中务必使用双引号包裹完整分支名。
本地有未提交修改时
建议先 Commit 或 Stash，再进行切换/重命名操作。
团队协作提醒
重命名后，建议在团队群组中简单通知，并告知其他人如何切换到新分支，避免他人继续使用旧分支名。

五、总结#

步骤	命令行	TortoiseGit
重命名本地	`git branch -m 新名字`	右键 → Rename（部分版本支持）
推送新分支	`git push -u origin 新名字`	推送时选择新分支
删除远程旧分支	`git push origin --delete 旧名字`	Browse References → Delete
清理跟踪信息	`git fetch --prune`	Fetch 时勾选 Prune

按照以上流程操作，即可安全完成分支重命名，既不会丢失历史，也不会破坏与其他分支的关联关系。

PVE 创建 LXC 容器全流程，以及它与 KVM 虚拟机的区别

Sat, 17 Oct 2026 00:00:00 GMT

用 Proxmox VE（PVE）的时候，创建工作负载有两个入口：右上角的「创建虚拟机」（KVM）和「创建 CT」（LXC）。两者看起来只是向导页面不一样，实际上底层原理差别很大，内存、磁盘、稳定性的表现也都不同。

这篇文章先介绍一下 LXC 的创建流程（基于 PVE 9.1.1 的中文界面），再系统对比 LXC 和 KVM。

一、先搞清楚 LXC 和 KVM 是什么#

	LXC	KVM
本质	容器，和宿主机共用同一个内核	完整虚拟机，有独立的内核和虚拟硬件
隔离方式	namespace + cgroup	硬件虚拟化（QEMU + KVM）
能运行的系统	只能是 Linux（共用宿主机内核）	Linux、Windows、BSD 等几乎都行
启动速度	秒级	要完整走一遍开机流程
资源开销	很小	相对较大

一句话概括：LXC 是”轻量级的隔离环境”，KVM 是”一台完整的虚拟电脑”。

二、创建 LXC 容器的完整流程#

点击右上角的「创建 CT」，会打开创建向导，顶部依次是：常规 → 模板 → 磁盘 → CPU → 内存 → 网络 → DNS → 确认。

1. 常规#

选项	说明
节点	创建到哪个 PVE 节点，单机环境只有一个
CT ID	容器的唯一编号，PVE 会自动给出下一个可用编号（例如 101），虚拟机和容器共用同一套编号
主机名	容器的 hostname，必填
资源池	可选，用来给一批容器或虚拟机分组、做权限管理
无特权的容器	建议保持勾选。容器里的 root 会被映射为宿主机上的普通用户，安全性更高
嵌套	勾选后容器里可以再跑 Docker 之类的东西，需要的话保持勾选
Add to HA	加入高可用，单机环境不用管
密码 / 确认密码	容器 root 用户的密码，必填（和 SSH 公钥二选一或都填）
SSH 公钥	可粘贴公钥，也可以点「加载SSH密钥文件」导入，之后可免密登录

关于「无特权的容器」：它安全，但访问宿主机设备、挂载某些文件系统时会有权限限制。如果必须用特权容器，要清楚它的风险。

2. 模板#

LXC 不是用 ISO 安装系统，而是从模板解压出一个根文件系统。

选择存储（通常是 local）和模板文件，例如 debian-12-standard、ubuntu-24.04-standard
如果下拉列表里没有模板，需要先下载：在左侧选中存储（如 local）→ CT 模板 → 模板，选择想要的系统点击下载
模板文件名里的版本号会随时间更新，以你实际看到的为准

3. 磁盘#

选择存储位置，设置根磁盘大小（GiB）
要点：LXC 的磁盘只能调大，不能调小，所以不用一开始给太多，用多少给多少，之后再扩

4. CPU#

设置核数，这是限制容器最多能用几个核
同样是上限，不是独占，容器空闲时不会占用这些核
之后可以在线修改

5. 内存#

内存（MiB）：内存上限
交换空间（MiB）：容器的 swap 额度，可以设为 0 或较小的值

这里是 LXC 和 KVM 最大的区别之一：LXC 的内存本质是 cgroup 的上限，不会预先占用，用多少占多少，释放后宿主机能立刻拿回去（详见下文对比）。

6. 网络#

名称：容器内的网卡名，默认 eth0
桥接：默认 vmbr0，也就是和宿主机在同一个局域网
IPv4：选择 DHCP（由路由器分配）或 静态（手动填 IP/CIDR 和网关）
IPv6、VLAN 标签、防火墙按需设置

建议在路由器里给容器做 DHCP 保留，或者直接设静态 IP，方便以后固定访问。

7. DNS#

默认「使用主机设置」就行
也可以手动指定 DNS 域和 DNS 服务器

8. 确认#

检查所有配置是否正确
勾选「创建后启动」可以创建完立刻开机
点击「完成」，在底部任务栏里能看到创建任务，状态为 OK 就成功了

三、命令行创建（可选）#

如果想批量创建或写成脚本，可以直接用 pct：

Terminal window

1
# 创建容器 101（模板文件名请以实际下载的为准）
2
pct create 101 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
3
  --hostname demo \
4
  --memory 2048 \
5
  --swap 512 \
6
  --cores 2 \
7
  --rootfs local-lvm:8 \
8
  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
9
  --unprivileged 1 \
10
  --features nesting=1 \
11
  --password \
12
  --start 1

创建后常用的管理命令：

Terminal window

1
pct start 101      # 启动
2
pct stop 101       # 停止
3
pct enter 101      # 直接进入容器的 shell
4
pct set 101 --memory 4096   # 在线调整内存上限
5
pct config 101     # 查看配置

四、LXC 与 KVM 的核心区别#

1. 内存：上限 vs 向宿主机申请#

LXC

设置的内存是 cgroup 的上限（memory.max）
容器启动时不会预先占用，用多少占多少，释放后宿主机立刻拿回
宿主机不会主动”抽走”容器的内存，所以没有 Ballooning 那种因为被回收而死机的问题
超过上限时，内核先回收容器自己的缓存，不够再触发 cgroup OOM，只会杀容器里的进程，不会拖垮宿主机

KVM

虚拟机有独立的内核，宿主机看到的只是 QEMU 进程占用的内存
客户机用过的内存（包括缓存）QEMU 会一直占着，即使客户机已经释放，所以 PVE 里的内存用量常常偏高，甚至接近 100%
想让内存可回收需要开启 Ballooning，但这个功能在某些场景下容易引发卡死（OOM、驱动问题、与 PCI 直通不兼容等），稳定性优先的话，很多人会选择关闭

2. 内存可见性#

	LXC	KVM
PVE 里显示的内存	实时、准确	默认只是 QEMU 进程占用
想看客户机内部真实用量	不需要额外配置	需要 QEMU Guest Agent，或在虚拟机内部监控

建议：KVM 虚拟机安装并启用 QEMU Guest Agent。它常驻内存只有几 MB 到十几 MB，对内存几乎没有影响，却能带来更准确的状态显示、IP 显示、正常关机和一致性备份。

3. 热调整#

	LXC	KVM
修改内存	在线生效，无需重启	通常需要关机再开机（内存热插拔配置较麻烦）
修改 CPU 核数	在线生效	视配置而定
扩容磁盘	在线可调大	可调大，客户机内还要再扩分区和文件系统
缩小磁盘	不支持	同样不建议

创建时设错了也不用慌，LXC 随时都能改。

4. 隔离性与兼容性#

KVM 隔离更彻底：拥有独立内核，一个虚拟机的内核崩溃不会影响其他。可以运行 Windows、可以安装不同内核版本，也支持显卡、HBA 等 PCI 直通
LXC 隔离相对弱：所有容器共用宿主机内核，如果宿主机内核出问题，所有容器一起受影响。只能运行 Linux，容器里也不能随意换内核、加载内核模块
需要内核级功能的软件（某些 VPN、需要特殊内核模块的程序等）在 LXC 里可能跑不起来或需要额外配置

5. 资源占用与启动速度#

LXC 没有虚拟硬件层，也不需要完整开机流程，CPU 和内存开销很小，通常几秒就能启动
KVM 需要模拟硬件、引导系统，开销更大，但换来了更完整的兼容性

6. 备份与迁移#

两者都支持 PVE 自带的备份（vzdump）和快照，用法基本一致
LXC 的备份体积通常更小、速度更快
KVM 的备份可配合 Guest Agent 做一致性冻结

五、怎么选？#

适合用 LXC 的场景

轻量级 Linux 服务：Nginx、数据库、各类 Web 应用、DNS、监控、下载工具等
追求资源利用率，想在一台机器上跑很多个服务
需要频繁调整内存、CPU，不想重启

适合用 KVM 的场景

需要运行 Windows 或其他非 Linux 系统
需要独立内核、特殊内核模块
需要 PCI 直通（显卡、网卡、HBA 等）
对安全隔离要求高，不放心共用内核

一个简单的经验：能用 LXC 的 Linux 服务就用 LXC，需要完整系统或强隔离时再用 KVM。

总结#

LXC 创建流程简单：常规 → 模板 → 磁盘 → CPU → 内存 → 网络 → DNS → 确认
LXC 的内存、CPU 都是上限，按需使用，在线可调；磁盘只能扩不能缩
KVM 是完整虚拟机，内存默认被 QEMU 占住不归还，要看真实用量需要 Guest Agent
Ballooning 收益不稳定、坑多，稳定优先可以关闭，只保留 Guest Agent
轻量 Linux 服务选 LXC，Windows、直通、强隔离选 KVM

两者并不是谁取代谁，在同一台 PVE 上混用，才是最合理的方式。

把 Waline 评论系统从本地 Docker 免费迁移到 Vercel + TiDB

Fri, 16 Oct 2026 00:00:00 GMT

之前我的博客评论系统 Waline 一直跑在家里 Ubuntu 的 Docker 里，用的是 SQLite。这套方案能用，但依赖家里的机器和网络一直在线。这次把它迁到了 Vercel，数据库换成 TiDB Cloud，全程免费，这里记录一下过程和踩到的坑。

先回答两个问题#

Waline 算动态网页，要收钱吗？

Waline 是动态服务（评论的读写要走后端 API），但它是 Serverless 架构，可以跑在 Vercel 上。Vercel 的 Hobby 计划永久免费，但只允许个人、非商业用途，个人博客的评论系统没问题。另外 Hobby 有用量上限，超限后是停止服务而不是扣费，普通博客基本用不到。具体额度以 Vercel 官网为准。

为什么必须换数据库？

Vercel 的文件系统是只读、无状态的，SQLite 这种本地文件数据库没法用。所以需要一个云数据库。Waline 支持 LeanCloud、MySQL、MongoDB、PostgreSQL 等，我选了 TiDB Cloud Serverless（兼容 MySQL，有免费额度，Waline 官方文档有专门教程）。

选 MySQL 系而不选 PostgreSQL 的原因是：从 SQLite 导出的 INSERT 语句基本能直接导入 MySQL，而 PostgreSQL 要额外处理列名大小写和类型差异。

几个方案的对比#

迁移前我也对比过几个方向：

方案	结论
Vercel + TiDB	Waline 官方默认方案，文档齐全，最稳
Cloudflare Workers + D1	D1 是免费数据库，但 Waline 官方不支持，后端也要改造，不推荐
Render 免费档	免费服务会休眠，唤醒要几十秒，评论区加载体验差
Cloudflare Tunnel + 现有 Docker	不用迁移数据，最省事，但依赖机器常开

如果机器 24 小时开着，Cloudflare Tunnel 是最省力的选择；想摆脱本地机器，就走 Vercel + TiDB。

迁移步骤#

1. 导出 SQLite 数据#

先确认数据文件和数据量：

Terminal window

1
cd ~/docker/waline
2
ls -la data
3
sqlite3 data/waline.sqlite ".tables"
4
sqlite3 data/waline.sqlite "select count(*) from wl_Comment; select count(*) from wl_Users; select count(*) from wl_Counter;"

迁移前先备份一份：

Terminal window

1
cp -r data data_backup

然后把三张表导出成带列名的 INSERT 语句：

Terminal window

1
cd data
2
for t in wl_Users wl_Comment wl_Counter; do
3
  sqlite3 waline.sqlite ".headers on" ".mode insert $t" "select * from $t;" > $t.sql
4
done

.headers on 会让 INSERT 带上列名，避免列顺序不一致。

导出的文件里包含管理员的密码哈希和访客 IP 等信息，这些文件不要上传到公开仓库。

2. 在 TiDB Cloud 建库建表#

注册 TiDB Cloud，创建一个 Serverless 集群，记下 Host、Port（4000）、用户名、密码。
创建数据库 waline。
使用 Waline 官方提供的 MySQL 建表脚本，创建 wl_Comment、wl_Counter、wl_Users 三张表。

3. 导入数据（这里有个坑）#

我直接在 TiDB 网页的 SQL Editor 里粘贴导出的 SQL 执行，结果报了语法错误：

1
Parsing sql failed ... near ""like",ua,url,createdAt,updatedAt) ...

原因是 SQLite 导出的列名用的是双引号（"like"、"2fa"），而 MySQL/TiDB 里双引号会被当成字符串，列名要用反引号。like 还是 MySQL 的保留字，必须加反引号。

所以导入前需要替换：

Terminal window

1
sed -i 's/"like"/`like`/g' wl_Comment.sql
2
sed -i 's/"2fa"/`2fa`/g' wl_Users.sql

用网页编辑器的话，直接手动把这两处改成反引号也行。wl_Counter 里没有这类列名，可以原样导入。

如果用命令行客户端导入，建议先执行一句，避免评论里的反斜杠被 MySQL 当成转义符：

1
SET SESSION sql_mode = CONCAT(@@sql_mode, ',NO_BACKSLASH_ESCAPES');

导入后核对条数是否和 SQLite 一致：

1
SELECT COUNT(*) FROM wl_Users;
2
SELECT COUNT(*) FROM wl_Comment;
3
SELECT COUNT(*) FROM wl_Counter;

4. 部署 Waline 到 Vercel（第二个坑）#

我一开始直接 fork 了 Waline 的整个 GitHub 仓库，然后在 Vercel 里导入。Vercel 把它识别成了 docs（文档站）、server（Container）和 app（前端）三个子项目，没有一个是能直接部署的评论服务。

正确做法是使用 Waline 官方文档「Vercel 部署」页面里的 Deploy 按钮。它会基于一个很小的模板，在你的 GitHub 下创建新仓库，模板里引用的是已发布的服务端包，部署后就是可用的评论服务。之前 fork 的仓库可以删掉。

第一次部署因为还没配数据库，打不开或报错是正常的。

5. 配置环境变量（第三个、第四个坑）#

在 Vercel 项目的 Settings → Environment Variables 里添加变量。

数据库变量要用 Waline 官方 TiDB 教程里的 TIDB_* 这一组，而不是通用的 MYSQL_*：

变量	值
`TIDB_HOST`	TiDB 集群的 Host
`TIDB_PORT`	`4000`
`TIDB_DB`	`waline`
`TIDB_USER`	用户名（Serverless 的用户名带有前缀，要完整复制）
`TIDB_PASSWORD`	密码
`JWT_TOKEN`	随机字符串，建议新生成，不要沿用旧的
`SITE_NAME`	站点名称
`SITE_URL`	博客地址
`AUTHOR_EMAIL`	博主邮箱

几点说明：

变量类型：密码和 JWT_TOKEN 选 Secret（保存后不可回看）；Host、端口、库名等选 Config，方便以后核对。用户名带前缀容易漏，建议选 Config。
环境选 Production 即可。
我原来在 Docker 里设置了 TZ，在 Vercel 上加这个变量会提示 reserved（系统保留名），不能设置，直接跳过。评论时间在前端会按浏览器本地时区显示，不影响使用。
改环境变量不会自动触发部署，要到 Deployments 里对最新一次部署点 Redeploy 才生效。

6. 验证#

部署完成后：

打开 https://你的vercel域名/ui，用博主账号登录，说明用户表导入成功。
在评论管理里能看到旧评论，说明评论表导入成功。
打开服务根路径时评论区是空的，这是正常的，因为 Waline 的评论按页面路径存储，示例页的路径是 /，旧评论属于你博客里的各个页面路径。

评论时间在管理页里会比数据库里的值多 9 个小时，这是因为数据库存 UTC，页面按东京时区显示，不是数据错误。

7. 收尾#

把博客前端 Waline 配置里的 serverURL 改成新的地址，本地预览确认旧评论和浏览量都在。
在 Vercel 项目的 Settings → Domains 绑定自己的子域名（DNS 加 CNAME），前端改用这个域名。*.vercel.app 在国内访问不太稳定，绑自己的域名也方便以后更换部署而不改前端。
确认一切正常后，再添加 SECURE_DOMAINS 环境变量做安全域名白名单，多个域名用英文逗号分隔，不带 https://，然后 Redeploy。先测通再加白名单，出问题时好定位。
最后 docker compose down 停掉本地容器，data 备份先保留一段时间。

关于后续更新#

Vercel 关联了 GitHub 仓库，每次 push 到生产分支都会自动拉取代码并重新部署，不需要手动操作。例外是改环境变量，必须手动 Redeploy。

总结#

整个迁移的核心其实就两件事：把 SQLite 数据搬到云端 MySQL 兼容数据库，以及用官方模板部署服务端并配好环境变量。踩的坑集中在三处：

SQLite 导出的双引号列名在 MySQL 里要换成反引号；
不能直接 fork 整个 Waline 仓库部署，要用官方的一键部署模板；
TiDB 要用 TIDB_* 变量，TZ 在 Vercel 上是保留名不能设置。

迁完之后评论服务不再依赖家里的机器，Vercel 和 TiDB 的免费额度对个人博客也足够了。

父母亲朋想来日本玩需要申请的签证说明

Wed, 07 Oct 2026 00:00:00 GMT

父母想来日本玩：旅游签证 vs 短期滞在（探亲）签证的区别与完整申请流程#

很多在日本生活的朋友想邀请父母来日本玩，却经常被两个概念搞混：

旅游签证
短期滞在签证（探亲）

其实两者在法律上都属于**「短期滞在」**（Temporary Visitor），但申请目的、材料要求和操作方式有明显区别。

一、两者的本质关系#

项目	旅游签证	短期滞在（探亲）签证
官方名称	短期滞在（观光）	短期滞在（親族訪問）
在留资格	短期滞在	短期滞在
最长停留	通常15天或30天（个别情况可达90天）	通常15天、30天或90天
是否可工作	完全禁止	完全禁止
是否需要COE	不需要	不需要
申请地点	中国当地日本使领馆指定机构	中国当地日本使领馆指定机构

核心结论：
两者都是短期签证，不是两种完全不同的签证，只是申请时填写的「渡航目的」不同，导致材料和审查侧重点不一样。

二、主要区别对比#

对比项	旅游签证（观光）	短期滞在探亲签证（親族訪問）
主要目的	旅游观光	探望在日亲属
日本侧是否需要邀请人	通常不需要（旅行社担保）	需要（你作为招へい人）
你需要准备的材料	基本不需要	招へい理由書、身元保証書、住民票等
父母需要准备的材料	财力证明 + 行程 + 在职等	亲属关系证明 + 你寄去的材料
申请渠道	指定旅行社	指定签证代理机构
审查重点	行程是否合理、有无足够资金、回国意愿	亲属关系是否真实、是否有长期滞在意图
通过难度	财力好、行程清晰时较顺利	关系明确时通常也不难
适合人群	父母经济条件较好，纯粹想旅游	明确是来看你，或父母经济条件一般

三、旅游签证申请流程（父母主导）#

适合情况：父母自己经济条件不错。

申请步骤#

选择指定旅行社
比如南京属于上海总领事馆管辖，必须通过上海总领事馆指定的旅行社办理，不能自己直接去领事馆。
准备材料（父母侧）
- 护照原件
- 签证申请表 + 照片
- 户口本复印件
- 在职证明 / 退休证明
- 银行存款证明或流水（重点）
- 往返机票预订单 + 酒店预订单（通常由旅行社安排）
- 行程表
提交申请
父母本人携带材料到指定旅行社提交。
等待结果
通常受理后4–5个工作日出结果。
领取签证
获批后护照贴签。

优点：你几乎不用准备材料。
缺点：对父母的财力要求相对更高。

四、短期滞在探亲签证申请流程（你需要配合）#

适合情况：父母经济条件一般，以及现在比较严苛的政策环境。

整体流程#

你在日本准备材料
把材料发给父母（电子版打印即可）
父母在中国准备自己的材料
父母去指定代理机构提交
等待审查并领取签证

你需要准备的材料（日本侧）#

招へい理由書（招聘理由书）
身元保証書（身份保证书）
住民票（记载全员及续柄）
在留卡正反面复印件
在职证明或收入证明（推荐）
滞在予定表（停留预定表）

重要：这些材料可以扫描后发给父母打印提交，一般接受复印件。

父母需要准备的材料#

护照原件
签证申请表 + 照片
户口本复印件（需出示原件）
亲属关系公证书（非常重要）
在职/退休证明
财力证明（根据情况）

申请地点#

比如南京属于日本国驻上海总领事馆管辖。
必须通过上海总领事馆指定的代理申请机构提交，父母本人必须到场。

五、哪种更适合父母来玩？#

情况	推荐签证
父母经济条件好，主要想旅游	旅游签证
明确是来看你，住你家	探亲签证
父母退休、收入证明较弱	探亲签证更有优势
你想减少自己的材料准备	旅游签证
想让审查官更容易理解“就是来看儿子/女儿”	探亲签证

实务建议：
大多数在日工作的人，更推荐直接申请探亲签证。因为目的明确，审查官对“为什么来日本”的疑虑更少。

六、常见注意事项#

两种签证都不能在日本工作，也基本不能延期。
签证有效期通常是签发后3个月内入境一次。
拒签后，同一目的一般需要等待约6个月才能再申请。
材料一定要真实、前后一致，千万不要造假。
电子版材料可以打印提交，但签名必须是你亲笔签名的扫描件。

七、总结#

项目	旅游签证	探亲签证
你的工作量	很少	需要准备材料
父母的工作量	较多（财力+行程）	中等
通过逻辑	证明“有钱旅游并会回国”	证明“真的是来看亲属”
推荐指数	★★★☆☆	★★★★☆

ICOM IC-705 前面板按键功能详解

Tue, 22 Sep 2026 00:00:00 GMT

ICOM IC-705 前面板按键功能详解#

ICOM IC-705 是一款非常受欢迎的便携式全模式电台（HF/VHF/UHF），采用 4.3 英寸彩色触摸屏 + 少量物理按键的设计。虽然触摸屏承担了大部分操作，但前面板上的物理按键和旋钮依然是日常使用中最频繁接触的部分。

本文根据官方 Basic Manual 和实际操作体验，按位置从左到右、从上到下，详细说明每个按键与旋钮的功能。

左侧区域#

1. TWIN PBT（双通带调谐旋钮）#

短按：在 PBT1 和 PBT2 之间切换，然后旋转调整通带偏移量。
长按 1 秒：清除当前 PBT 设置，恢复默认。

这是 IC-705 非常实用的干扰抑制工具，特别适合 SSB 和 CW 模式下消除邻近信号干扰。

2. POWER 指示灯#

绿色常亮：电台已开机。
绿色闪烁：进入屏保模式。
橙色常亮：显示屏关闭（待机显示）。
橙色闪烁：待机模式。

3. POWER 按键#

短按：开机。
长按约 1 秒：关机。

4. VOX / BK-IN 按键#

短按：开启或关闭 VOX（语音触发发射）功能。
在 CW 模式下，同一按键用于开启/关闭 Break-in（半自动或全自动断续）功能。

注意：此按键可在菜单中自定义其他功能。

5. CALL / DR 按键#

短按：在 Call 信道模式与 VFO/Memory 模式之间切换。
长按 1 秒：开启或关闭 DR（D-STAR Repeater） 功能。

这是使用 D-STAR 数字通信时的重要快捷键。

6. AF / RF / SQL 旋钮#

旋转：调节音量（AF Gain）。
短按：进入设置菜单，可切换调整 RF Gain（射频增益） 或 SQL（静噪） 电平。

这是使用频率最高的旋钮之一。

底部中央五个按键#

这五个按键位于触摸屏正下方，是最核心的操作区：

按键	功能
MENU	打开主菜单画面
FUNCTION	打开 FUNCTION 画面（预放、衰减、AGC、Notch、NB、NR、Split 等常用功能）
M.SCOPE	短按：显示迷你频谱仪长按 1 秒：显示完整频谱仪/瀑布图
QUICK	打开快速菜单（常用设置快捷入口）
EXIT	退出当前设置画面，或返回上一级画面

右侧区域#

7. MULTI 多功能旋钮 + 按键#

短按：打开多功能菜单（RF Power、MIC Gain、COMP、Monitor 等）。
旋转：调节当前分配的参数值。
在 RIT / ∂TX 激活时，旋转可直接调整偏移量。

这是 IC-705 最灵活的控制部件，很多参数都通过它调节。

8. RIT / ∂TX 按键#

短按：开启或关闭 RIT（接收增量调谐）或 ∂TX（发射频率偏移）功能。
长按：在 RIT 与 ∂TX 之间切换。

RIT 可在不改变发射频率的情况下微调接收频率（最大 ±9.99 kHz），非常实用。

9. XFC（发射频率检查）按键#

在 Split 或双工模式下：按住可监听发射频率。
在单工模式下：可临时打开静噪并关闭噪声抑制，方便检查信号。

10. MPAD（Memo Pad）按键#

短按：依次调出 Memo Pad 中保存的内容。
长按 1 秒：将当前频率、模式等内容保存到 Memo Pad。

相当于快速便签功能，适合临时记录频率。

11. SCAN 按键#

短按：打开 SCAN SELECT 画面。
长按 1 秒：启动上次选择的扫描方式。

12. AUTOTUNE / RX>CS 按键#

CW 模式：短按可自动调谐到附近的 CW 信号。
DV（D-STAR）模式：
- 短按：显示接收历史列表。
- 长按 1 秒：捕获最新接收到的呼号（或中继器）作为临时目标。

此按键也可在菜单中自定义。

13. SPEECH 按键#

短按：语音报读当前频率和模式（日语/英语可选）。

14. 主调谐旋钮（Main Dial）#

旋转：改变工作频率。
支持自动调谐步进（根据旋转速度自动改变步进大小）。
可开启 1 Hz 精细调谐、1/4 调谐等功能。

15. TX/RX 指示灯#

绿色：接收状态。
红色：发射状态。

总结与使用建议#

IC-705 的前面板设计非常紧凑，物理按键数量虽然不多，但每个按键都经过精心设计，且支持长按实现第二功能。日常操作中最常用的组合是：

AF 旋钮 调节音量
MULTI 旋钮 调节功率、MIC 增益等
FUNCTION 快速开关预放、噪声抑制等
M.SCOPE 查看频谱
RIT 微调接收频率

建议新手先熟悉这几个核心按键，再逐步探索触摸屏菜单中的高级功能。

希望这篇详解能帮助你更快上手 IC-705！如果有具体操作问题，欢迎留言讨论。

参考资料：ICOM IC-705 Basic Manual（官方英文版）

日本无线技士考试与业余无线电开局指南

Mon, 21 Sep 2026 00:00:00 GMT

日本无线技士考试与业余无线电开局指南（2026年）#

想在日本玩业余无线电（アマチュア無線），需要先取得无线従事者资格（无线技士），再办理无线局执照（开局）。
本文将系统整理：考试地点、外国执照的处理方式，以及开局的完整手续与费用（基于2025年10月1日之后的最新规定）。

1. 日本无线技士考试只能在日本国内参加吗？#

是的，目前只能在日本国内参加。

日本无线协会（公益財団法人日本無線協会）是指定考试机构，负责全部23种无线従事者国家考试。考试地点全部位于日本本土：

定期笔试（非CBT）：主要集中在东京、札幌、仙台、长野、金泽、名古屋、大阪、广岛、松山、熊本、那霸等城市。
CBT方式（电脑考试）：适用于第三级/第四级业余无线技士、第二级/第三级海上特殊无线技士、第二级/第三级陆地特殊无线技士等，全年可考，全国约300多个测试中心，但全部在日本国内。

官方资料中没有任何海外考点或国外考试安排。
国籍不限，外国人也可以报考，但必须亲自到日本国内考场参加，考试语言为日语。

提示：第三级、第四级业余无线技士采用CBT方式，预约灵活，适合短期访日时参加。

2. FCC等欧美业余无线电执照可以免试换发日本执照吗？#

不能直接换发日本的「无线従事者免許证」。

日本与部分国家签订了业余无线电相互承认（相互運用）协定。持有这些国家有效业余无线资格的人，可以在日本直接操作业余无线局，无需先取得日本的无线従事者资格。

主要对象国家#

美国（FCC）、加拿大、德国、法国、澳大利亚、韩国、芬兰、爱尔兰、秘鲁、新西兰、印度尼西亚
以及CEPT部分国家（对日本第一级业余无线技士有额外安排）

美国FCC对应关系示例#

FCC资格	对应日本级别	可操作范围
Amateur Extra	第一级业余无线技士	第一级全部范围
Advanced	第二级业余无线技士	第二级全部范围
General / Conditional / Technician	第四级业余无线技士	第四级范围
Novice	第三级业余无线技士	第三级范围

重要区别：

这只是操作权限的相互承认，并不会发给你日本的无线従事者执照。
仅适用于业余无线，业务用资格（综合、海上、航空、陆地特殊等）不适用。
使用时通常需要向总务大臣（通过综合通信局）进行登记等手续。

如果希望长期在日本操作，或需要业务用资格，建议直接参加日本国家考试取得正式资格（资格终身有效）。

3. 日本业余无线电台开局手续（2026年最新）#

开局需要两样东西：

无线従事者资格（第四级以上业余无线技士）
无线局执照（アマチュア局の免許）

开局整体流程#

取得无线従事者资格
- 国家考试合格，或
- 参加养成课程（JARD等）并修了
准备无线设备
- 推荐使用带技适标志（技術基準適合証明）的设备，手续最简单。
- 无技适标志的设备（自作机、改造机、旧机等）需先到JARD办理保证认定。
向总务省申请开局
- 推荐使用电子申请（電波利用電子申請）：https://www.denpa.soumu.go.jp/
- 也可书面申请（邮寄到管辖综合通信局）。
审查与缴费
- 通常审查时间约3～4周。
- 电子申请会收到缴费通知，通过Pay-easy等方式支付。
领取数字执照
- 2025年10月1日起，纸质执照已全面废止，改为数字执照记录（免許記録）。
- 登录电子申请系统即可查看、下载或打印。

电子申请推荐步骤（技适设备）#

在「電波利用電子申請」注册账号。
选择「アマチュア局専用の簡易な手続き」→「開局申請」。
填写无线従事者免許证信息、设备技适编号、设置场所等。
提交后等待审查与缴费通知。
缴费完成后即可在系统中查看数字执照。

无技适设备时，需先完成JARD保证认定，再在申请中上传保证书。

4. 开局相关费用（2025年10月1日改定后）#

主要手续费（电子申请 vs 书面申请）#

项目	电子申请	书面申请	备注
开局申请（50W以下）	2,750円	4,530円	第四级、第三级通常适用
开局申请（50W超）	5,400円	8,480円	第二级、第一级高功率时
再免許（更新）	1,700円	3,330円	每5年一次
无线従事者免許申请	1,750円	约2,050円	取得资格后申请
免許事项证明书交付	440円	480円	需要纸质证明时另付

其他可能费用#

JARD保证认定（无技适设备）：基本保证约5,500円/台起
电波利用料（个人局）：每年300円（可预缴）
国家考试手续费（参考）：第四级约5,100円（2026年10月可能调整）

最经济路径示例（第四级 + 技适设备 + 电子申请）#

国家考试：约5,100円
従事者免許申请：1,750円
开局申请：2,750円
电波利用料（首年）：300円
合计约9,900円（不含无线机本身）

5. 实用建议与注意事项#

强烈推荐电子申请：手续费更低、进度可查、数字执照即时可用，且支持手机操作。
执照有效期为5年，需在到期前6个月～1个月申请再免許。
无线従事者资格本身终身有效，无需更新。
外国人也可开局业余电台（无国籍限制），但在留期间可能影响执照期限。
使用外国资格在日本操作时，请确认是否已完成必要登记，并严格遵守对应操作范围。

参考官方渠道#

日本无线协会（考试）：https://www.nichimu.or.jp/
总务省电波利用门户：https://www.tele.soumu.go.jp/
电波利用电子申请：https://www.denpa.soumu.go.jp/
JARD（保证认定・养成课程）：https://www.jard.or.jp/
JARL（日本业余无线联盟）：https://www.jarl.org/

希望这篇指南能帮助你顺利开启日本业余无线电之旅。
如有具体资格对应表、设备选择或申请细节需要进一步确认，欢迎留言交流！

本文信息基于2026年9月公开资料整理，实际手续请以总务省最新规定为准。

日本便利店退换货

Tue, 15 Sep 2026 00:00:00 GMT

昨天在住所附近的便利店随手买了一只电子打火机，结果今天准备用的时候发现居然打不着火。

在无小票、额度小且已隔天的情况下，体验了一把日本便利店退换货流程。

第一次沟通：没有小票也能换吗？#

店员要求小票,但是我没有。之后他说要去查交易记录,要求提供交易时间。

我在paypay上找到了交易时间,他在 POS 机的历史日志里匹配到了昨天的流水。

繁琐的退换流程：“退全单”与“再会计”#

店员并没有直接从货架上拿个新的打火机递给我，而是开启了一套无比繁琐的流程：

查找全单：在 POS 机里调出我昨天买的所有商品明细。然后去货架上一件一件找到昨天买的所有东西。
全额退款（全額返品）：把昨天整笔交易彻底撤销退款。
重新扫码（再会計）：让我把昨天一起买的其他东西，重新再买一次，连同新打火机一起重新结一次账。
打印新凭证：新打火机给我，打火机以外的东西全部收回去。

整套流程折腾了几十分钟，只为了换一只两百日元的打火机。

意外插曲：还被“免费升舱”了？#

更神奇的是，在拿新打火机时，原先货架上的同款似乎卖光了。店员跑去后面的柜台，拿了一只更好的**防风打火机（ターボライター）**给我。

虽然价格可能有些许微小的差额，但在系统的重结账与坏品报损处理下，店员顺利帮我平了账，最终我没有补一分钱，拿着更好用的防风打火机走出了便利店。

为什么日本便利店退换货这么“折腾”？#

回到家查了下，为什么宁可费时费力重结全单，也不“直接拿个好的换给我，把坏的放回货架最里面” 简单方便。

这其实体现了日本便利店文化中的几个核心逻辑：

1. POS 机的绝对库存管理#

便利店的收银系统对每件商品（SKU）的进出有着极严苛的追踪。如果不走“退货+重扫”流程，系统里的库存数量就会对不上。

2. 坏品报损（不良品処理）的合规性#

坏掉的打火机需要作为“故障品/不良品”退给供货商或总部报销。只有在系统里走正规退货程序，这只打火机才能被合法标记并扔进报废箱，而不是算作“店员私自拿走商品”或“未知损耗”。

3. 杜绝二次投诉与监控审计#

如果店员贪图省事把坏打火机重新挂回货架，很可能会被下一个顾客买走导致二次投诉；而收银台上的摄像头和防损审计，也禁止店员未经系统记录私下与顾客调换商品。

实用小结与常用日语#

如果你也在日本遇到类似买到故障商品、但又没留小票的情况，可以参考以下流程与对话：

出示商品与支付记录：即使没有纸质小票，PayPay、交通卡（Suica）等电子支付记录也可以作为凭证。
礼貌说明情况：
- 昨日ここで買った[商品名]が点かない（壊れている）んですけど。
  (昨天在这里买的[商品名]打不着/坏了。)
- レシートはないんですが、交換してもらえますか？
  (虽然没有小票，请问可以帮我换一个吗？)

只要态度诚恳、商品确实存在质量问题，店员都会严格按照规范帮你处理好！

DBeaver 与 A5M2 的对比

Wed, 02 Sep 2026 00:00:00 GMT

DBeaver 与 A5M2 对比#

日常做数据库开发时，我长期在 DBeaver 和 A5 Mk-2（以下简称 A5M2）之间反复横跳。
公司默认推荐 A5M2，而我个人更喜欢 DBeaver 的某些功能。两者各有明显优劣，尤其是在「数据复制粘贴」和「结果集展示」上差异巨大。

这篇文章把我实际踩过的坑和体验全部写出来，方便有同样困扰的人快速做选择。

一、核心差异总览#

对比维度	DBeaver	A5M2	胜者
查询结果直接显示字段别名	优秀（建表时的 Comment 直接显示）	较弱（必须写 AS 才会显示）	DBeaver
补全提示框直接显示字段别名	否	是	A5M2
检索字段直接编辑	非常方便	几乎不支持	DBeaver
多schema的search_path支持	有缺陷（能检索但是有警告找不到表）	完美支持	A5M2
NULL 显示方式	`[NULL]`	`« NULL »`	-
复制到 Excel 后再粘回数据库	必须用 Advanced Paste 直接粘贴会把一行全部贴到一个单元格直接粘贴无法识别自己复制出去的 `[NULL]`	直接粘贴即可	A5M2
整体轻量、启动快	很慢	很快	A5M2

二、DBeaver 真正好用的两个点#

1. 字段注释直接显示在结果集表头#

只要建表时给字段加了 Comment，DBeaver 在查询结果里会自动把注释显示在表头，完全不需要在 SQL 里写 AS。

这对接手别人表、或者字段名是英文缩写的场景极其友好。
A5M2 必须显式写 AS 别名 才会显示，否则表头永远是原始字段名。

2. 检索结果的直接编辑#

经常需要改某几个关键字段时，我习惯这样写：

1
SELECT status, * FROM your_table WHERE ...

DBeaver 可以直接修改status这个字段的值非常舒服。

A5M2 做不到这种直接修改的体验。只能

1
SELECT * FROM your_table WHERE ...

然后在几十上百个字段里左右拖动寻找status，然后他还无法显示别名，简直就是地狱。

三、A5M2 数据复制粘贴体验#

这是 A5M2 比较舒服的地方。

1. NULL 的显示与复制#

DBeaver：显示为 [NULL]，复制到 Excel 后还是 [NULL]
A5M2：显示为 « NULL »，复制到 Excel 后也是 « NULL »

2. 从 Excel 粘贴回数据库#

A5M2：直接 Ctrl+V 就能正确识别 « NULL » 为真正的 NULL，非常丝滑。
DBeaver：
- 普通 Ctrl+V：经常把整行数据全部塞进第一个字段，或者直接报错。
- 必须使用 Advanced Paste（Ctrl+Shift+V），并手动设置：
  - 勾选 Insert NULLs
  - NULL value mark 填写 « NULL » 或 [NULL]

每次都要打开 Advanced Paste 对话框，体验确实很差。

3. 实际工作流对比#

A5M2 流程（推荐）：

查询数据 → 复制到 Excel
在 Excel 里修改
直接粘贴回 A5M2 → 完成

DBeaver 流程：

查询数据 → 复制到 Excel
在 Excel 里修改
回到 DBeaver → 必须 Advanced Paste → 设置 NULL 标记 → 粘贴 → 完成

差距非常明显。

四、目前有没有完美工具？#

截至 2026 年，没有一款工具能完美兼顾两者优点：

像 DBeaver 一样自动显示字段注释 + 支持检索字段编辑
像 A5M2 一样 NULL 直接粘贴体验极佳

比较接近的选择有：

DataGrip：SQL 能力最强，数据编辑也还行，但 NULL 粘贴仍不如 A5M2
TablePlus / Beekeeper Studio：复制粘贴体验较好，但字段注释显示能力一般

在公司强制使用 A5M2 的前提下，最现实的做法是：

查询和重点字段修改用 DBeaver，需要和 Excel 大量交互时切回 A5M2。

五、给 DBeaver 用户的实用建议#

如果你必须继续用 DBeaver，记住以下几点可以少踩坑：

从 A5M2 / Excel 粘贴数据时，永远使用 Advanced Paste
把 NULL value mark 设为 « NULL »（可手动输入，它会记住历史）
需要同时支持 [NULL] 和 « NULL » 时，先分别用一次，让它们都进入下拉历史记录
普通 Ctrl+V 尽量少用，行为不稳定

结语#

DBeaver 和 A5M2 是两种完全不同思路的工具：

DBeaver 更像「开发者友好的全能客户端」
A5M2 更像「数据搬运和日常维护的效率工具」

没有绝对的好坏，只有适不适合你的工作流。
如果你主要做复杂查询和字段修改，DBeaver 更香；如果每天都要和 Excel 来回倒数据，A5M2 目前仍然是更省心的选择。

希望这篇文章能帮你少走一些弯路。

日本签证在线更新（在留期間更新許可申請）全流程踩坑与避坑指南

Wed, 12 Aug 2026 00:00:00 GMT

作为在日打工人，每次签证到期最头疼的就是去入管局排队。去品川或者出张所，基本上半天时间就白白耗掉了。

其实从近年开始，日本入管局的 在留申请在线系统（在留申請オンラインシステム） 体验已经大幅改善。只要你有一张 MyNumber 卡（个人编号卡） 和一部支持 NFC 读卡的智能手机，完全可以在家完成**“零排队”**签证更新！

本文总结了我近期亲自操作的完整流程、必备材料，以及过程中遇到的各种“奇葩报错”与避坑技巧，希望能帮你少走弯路。

💡 为什么强烈推荐线上申请？#

省时省力：完全不需要去入管局现场排队递交材料，24 小时随时提交。
补交材料极快：如果材料有遗漏，入管局会发邮件通知，直接在网页上传 PDF 即可，省去了挂号信邮寄往返的 1~2 周时间。
领卡可走邮寄：审核通过后，可以通过 “简易书留” 邮寄旧卡和印纸，新卡直接寄到家（虽然邮寄需要 extra 3~7 天，但不用去现场受罪）。

一、准备材料清单（以“技术·人文知识·国际业务”为例）#

如果你在同一家公司继续留任、未发生跳槽，材料其实非常简单，主要分为以下 5 部分：

1. 个人必备证件扫描件#

护照个人信息页（带有照片和护照号的页面，PDF 或 JPEG 格式）。
在留卡正反面（清晰的扫描件或照片）。
证件照电子版（单张照片，JPEG/PNG 格式，4:3 比例，纯色背景，3 个月内近照）。

2. 地方政府证明文件#

住民税的课税（或非课税）证明书 & 纳税证明书：去你居住地所在的市区町村役场（或利用 MyNumber 卡在便利店打印）开具最新年度的证明，并扫描为 PDF。

3. 公司发给你的申请表格#

公司填写并盖章/签发的 所属机关用申请表（2 页 PDF）。

4. 线上填写的“更新理由”#

续签（更新）不需要长篇大论写理由书！在系统输入框内填入一句标准定型文即可：
引き続き、現在所属している〇〇株式会社にて技術者として勤務を継続するため。

二、准备工具：无需购买 IC 读卡器！#

很多人以为电脑端申请必须买一个 USB IC 卡读卡器（ICカードリーダー），其实完全没必要：

电脑 + 手机“联合认证模式”（官方推荐）：
- 在电脑浏览器上填写和上传材料。
- 遇到身份认证时，网页会生成一个二维码。
- 用手机打开官方 マイナポータル App 扫码，将 MyNumber 卡贴在手机背面（NFC）即可完成认证！

⚠️ 注意：读卡时需要输入你当时在役场设置的 “署名用电子证书密码”（6~16 位大写字母+数字）。连续输错 5 次会被锁定，请务必提前确认密码。

三、详细操作流程与避坑指南#

整个流程分为 “两步走”：第一步开通系统权限（利用申出） →\rightarrow→ 第二步提交签证更新。

第一步：开通在线系统权限（利用申出）#

首次使用或在新版系统中登录时，你需要先向入管局提交“利用申出”，证明你是外国人本人。

登录系统并选择手续：在手续列表中选择 利用申出(新たに在留諸申請の実施を希望する外国人本人の方)（如果是已有权限账户更新状态，选择后缀为 _最新 的选项）。
手机扫码读取 MyNumber 卡：按照提示用手机 App 扫码并读取卡片，输入密码。
等待审核邮件（重点坑点！）：提交后，页面状态会显示为 処理待ち（等待处理）。
- ⚠️ 避坑点 1：这里不是秒过！因为后台需要批处理核验，通常需要 几十分钟到几个小时 不等。
- ⚠️ 避坑点 2：审核主要在**工作日（平日 9:00～17:00）**进行。如果是周末或夜间提交，可能要等下一个工作日才会通过。通过后你的邮箱会收到一封 利用申出完了通知 邮件。

第二步：进行真正的“在留期间更新许可申请”#

收到权限通过的邮件后，重新登录系统：

点击顶部导航栏的 「マイページ」（个人主页）或返回 「ホーム」（首页）。
找到 「在留諸申請」（或使用顶部的 手続き検索 搜索 “更新”）。
选择 「在留期間更新許可申請」。
依次填写个人信息、护照信息、公司信息、续签理由，并上传前面准备好的 PDF/照片附件。
中途保存技巧：如果填到一半要找材料，一定要点底部的 「入力中のデータを保存する」 下载本地暂存文件（.xml），防止网页超时导致填好的内容丢失！
检查无误后点击提交，拿到 “申请受理编号（申請受付番号）”。

四、踩坑报错与常见疑问解答#

❓ 报错提示：「入力された在留カード番号はすでに登録されています」#

原因：在留卡号在系统后台是“1 张卡只能绑定 1 次利用申出”。如果你之前用老账户绑定过，或者重复提交了「利用申出」，系统就会弹此报错。
解法：这说明你的卡号已经有权限了！不需要再去重复填写「利用申出」，直接退回主页去找 「在留期間更新許可申請」 的正餐入口提交即可。

❓ 审核通过后，怎么领取新在留卡？#

收到入管局发送的 許可通知メール（审查完成通知邮件）后，你可以选择邮寄领卡：

购买收入印纸：去邮局（郵便局）购买 4,000 日元 的“収入印紙（しゅうにゅういんし）”，贴在打印好的《手数料納付書》上。
准备材料：
- 贴好印纸的《手数料納付書》
- 现有的在留卡原件（入管打孔注销后会寄还给你）
- 护照个人信息页复印件
- 许可通知邮件的打印件
- 回邮信封（返信用封筒）：准备一个贴足邮票（建议简易书留，约 460~530 日元）并写好自己收件地址的信封。
邮寄与等卡：将上述材料通过挂号信寄给指定入管局，约 1~2 周内，打孔的旧卡和全新的在留卡就会寄到你家！

💡 安全提示：寄出旧在留卡至收到新卡期间，身上暂时没有实体卡。建议随身携带 许可通知邮件打印件 + 旧卡正反面清晰复印件 以备查验。

五、总结#

虽然日本行政系统的 UI 和交互偶尔让人吐槽（比如数据没打通、权限申请需要等工作日批处理等），但相比起亲自跑一趟品川入管局排队半天，线上申请依然是目前性价比最高、最省心的方案。

建议大家在签证到期前 1~2 个月 开始准备材料并提交，祝大家都能顺利拿到 3 年/ 5 年大签！

日本签证申请和更新需要 N2语言等级证书的说明

Tue, 04 Aug 2026 00:00:00 GMT

在申请或更新日本**“技术·人文知识·国际业务”签证**（以下简称“技人国签证”）时，“是否必须拥有 JLPT N2 证书”一直受聘人员和HR关注的焦点。

入国在留管理厅（入管局）实施了更加明确的审查规则。本文将为您详细梳理 N2 证书要求的适用对象、豁免条件、替代方案以及签证更新时的注意事项。

一、什么是“技人国”签证？#

“技术・人文知识・国际业务” 是日本最常见的工作签证类型之一，涵盖了绝大多数在日外籍白领岗位：

技术（Engineer）：软件工程师、IT架构师、机械/电子设计、数据分析等自然科学领域。
人文知识（Humanities）：市场营销、经营企划、财务会计、人事管理、B2B销售等。
国际业务（International Services）：翻译/口译、语言教学、跨境电商运营、海外公关与贸易实务等。

二、申请与更新签证时，真的强制需要 N2 吗？#

结论：并非所有人强制要求，但针对特定企业与岗位实行“原则上必须”制度。#

入管局针对“技人国”签证的语言审查进行了明确分级，是否需要提交 N2 证明主要取决于两个因素：雇主公司的分类（Category）与岗位实际使用的语言。

三、审查标准与适用人群划分#

1. 公司的四个分类（Category）#

日本入管局将接收机构（雇主）分为 4 个类别：

公司分类	定义	是否强制要求 N2/B2 证明？
第 1 类别	上市公司、政府机关、地方公共团体等	否
第 2 类别	上一年扣缴所得税额在 1,000 万日元以上的企业	否
第 3 类别	未上市且扣缴所得税额未满 1,000 万日元的中小企业	是（若岗位需使用日语）
第 4 类别	新设立企业、创业公司（Startup）、个人事业主	是（若岗位需使用日语）

2. 岗位与工作语言要求#

需要使用日语的岗位：如口译翻译、客服、业务联络、使用日文进行开发或文档撰写的工程师等。在属于第 3、4 类别企业任职时，必须提交 CEFR B2 相当（如 JLPT N2）的语言能力证明。
无需使用日语的岗位：如针对海外市场的全英文开发工程师、海外业务专员且公司内部沟通全为英语者，需在职务说明书中明确说明，可免予提交。

四、哪些人可以获得“豁免”？#

如果您属于以下任意一种情况，在申请或变更/更新“技人国”签证时，无需提供 JLPT N2 证书：

入职第 1 或第 2 类别企业（上市公司或高纳税额大企业）。
毕业于日本本土教育机构：持有日本的大学（学部/院生）、短期大学、高等专门学校或专门学校的毕业证书。
在留资格为“留学”且直接在日本转为工作签证：已有日本学历支撑。
在日本连续长期居住：在日本连续居住满 20 年以上者。
岗位完全无需使用日语：且雇主能向入管局出具合理的业务说明。

五、认可的日语能力证明清单#

除了最常见的 JLPT N2 证书外，入管局也认可达到 CEFR B2 同等水平的其他考试与证明：

JLPT（日本語能力試験）：N2 或 N1 合格证书
BJT（ビジネス日本語能力テスト）：400 分以上
其他认可考试：NAT-TEST（2级以上）、JLCT（JCT2以上）等达到 B2 标准的成绩
日本大学或专门学校学位证书

六、签证更新（Renewal）时的注意事项#

很多已在日本工作的工程师或文职人员关心：“我在更新签证时，会被查 N2 吗？”

公司未更换且岗位未变：
- 如果一直在同一家公司正常续签，审查重点在于纳税记录、违法记录以及公司经营状况，通常不需要补交 N2 证书。
发生换工作（跳槽）或社内调岗：
- 如果换到了一家 第 3 或第 4 类别的中小企业/新创公司，且新岗位需要使用日语沟通，在办理更新或在留资格变更时，入管局有权要求补交 N2/B2 语言证明。

七、给申请者与企业的建议#

1. 个人准备策略#

优先考取 JLPT N2 / BJT 400+：对于海外直接招聘（COE）或在中小型企业求职的人士，拿到 N2 证书能显著提升签证审批通过率，降低补件（理由书）风险。
保留学历证明与成绩单：如果在日本有就读经历，毕业证是极佳的免考证明。

2. 企业 HR 规范#

明确职务说明书（Job Description）：在开具雇佣合同与职务说明书时，如实填写语言使用需求。
确认企业类别：先确认公司属于 Category 1/2 还是 3/4，提前准备好《所属机关代表者申告书》及相关资质材料。

总结：N2 并不是所有“技人国”签证申请者的绝对硬性门槛，但对于赴日本中小企业或创业公司就职、且工作需使用日语 的人群而言，N2/CEFR B2 已是必备敲门砖。提前规划语言考证，是确保签证顺利下签的最佳保障。

企业邮箱与自定义域名别名转发的发信信任机制

Tue, 16 Jun 2026 00:00:00 GMT

在折腾自定义域名（例如 jcaonet.com）的邮件系统时，有一个疑问：

“既然我可以在 Cloudflare（CF）等域名管理面板里，手动给自己的域名加上 SPF、DKIM 和 DMARC 记录，那为什么用‘Gmail + CF 别名转发’的拼装方案，发信时依然比‘阿里企业邮箱’更容易被受信方丢进垃圾箱？这两者底层究竟有什么区别？”

简单来说：发信域名（你的域名）和实际投递服务器（阿里的 SMTP 或谷歌的 SMTP）确实不一样。但企业邮箱能安全着陆，而别名方案频繁翻车，是因为邮件生态中一套极其微妙的“代发机制”与“信头/信封域名对齐（Alignment）”在起作用。

一、核心技术误解：谁是真正的发信人？#

在技术层面，一封邮件其实有两个“发件人”，这是理解所有反垃圾协议的基础：

信封发件人（Return-Path / Envelope From）： 这是服务器之间握手、通信、处理退信用的底端域名（例如 admin@jcaonet.com）。
信头发件人（Header From）： 这是你在邮件客户端（如 Outlook、Gmail）界面上，直观看到的 From: admin@jcaonet.com。

受信方（如腾讯、谷歌、微软邮箱）在收到邮件时，会去严格对比：“这台自称是阿里或谷歌、IP 是 x.x.x.x 的服务器，凭什么帮 jcaonet.com 发邮件？”

如果没有妥善配置，这必然会被判定为钓鱼或垃圾邮件。

二、三大保驾护航的“铁三角”协议#

当你开通阿里企业邮箱时，服务商一定会要求你去域名服务商（如 Cloudflare、阿里云解析）那里配置几条特定的解析记录。正是这些记录消除了“域名与服务器不一致”的信任危机：

🛠️ SPF (Sender Policy Framework) —— 授权白名单
- 原理： 一条 TXT 记录，直接告诉全世界的接收服务器：“我允许哪些 IP 或域名帮我发邮件。”
- 配置： 阿里会让你加一条类似 v=spf1 include:spf.sg.aliyun.com -all 的记录。
- 结果： 接收方收到来自阿里 SMTP 的邮件，去查 jcaonet.com 的 SPF，发现里面写着“允许阿里帮我发”，信任度 +1。
🔑 DKIM (DomainKeys Identified Mail) —— 数字签名
- 原理： 阿里 SMTP 服务器在发送邮件时，会用一把私钥对邮件内容进行加密签名，附加在邮件头中。你则在域名解析里配置对应的公钥。
- 结果： 接收方收到邮件后用公钥解密。如果对得上，说明邮件在传输中没有被篡改，确实来自持证上岗的阿里服务器，信任度 +1。
👮 DMARC —— 终极对齐策略
- 原理： 基于 SPF 和 DKIM。它告诉接收方：“如果这两者验证失败了，说明有人在冒充我，请直接把邮件拒收（Reject）或者扔进垃圾箱（Quarantine）。”

三、为什么“Gmail 别名 + CF 转发”极易翻车？#

既然我们同样可以在 Cloudflare 里为 jcaonet.com 配置 SPF、DKIM 和 DMARC，为什么这种“拼装车”方案在发信时依然极易进垃圾箱呢？

目前 Cloudflare 的 Email Routing 只支持收信转发，并不支持免费的 SMTP 发信。所以当你使用 Gmail 的“代发别名（Send mail as）”功能发送 jcaonet.com 的邮件时，会遭遇以下两类致命的底层技术冲突：

1. 情况一：直接借用 Gmail 的公共服务器发信#

如果你在 Gmail 别名设置里，直接选择让 Gmail 代发，而不配置外部独立的 SMTP：

信封发件人 (Return-Path)： 会被强制重写为 你的谷歌账号@gmail.com（或者带有 bounce 标记的谷歌域名）。
信头发件人 (From)： 依然显示 you@jcaonet.com。
验证困境： 接收方服务器会去查信封域名（gmail.com）的 SPF，因为确实是谷歌服务器发的，SPF 顺利通过。但是！接收方接着会发现信封（gmail.com）和信头（jcaonet.com）完全不一致。 这直接触发了 DMARC 严格对齐失败。很多严格的接收方（如 Outlook、iCloud）会看到邮件上显示“由 gmail.com 代发”，或者直接将其判定为伪造垃圾邮件。

2. 情况二：在 Gmail 里配置了额外的第三方免费 SMTP#

为了解决上面的域名不一致，你可能会找一个第三方免费 SMTP（比如 Resend, Brevo 等）来冒充 jcaonet.com 发信：

DKIM 签名难题： 阿里企业邮会自动帮你发出的每封信盖上 jcaonet.com 的 DKIM 签名。而当你用 Gmail 客户端挂载第三方不成熟的 SMTP 别名发信时，Gmail 默认极难顺畅地使用你自定义域名的私钥去给邮件做纯正的 DKIM 加密签名，或者签名由于客户端二次封装被破坏。一旦没有完美的 DKIM 签名，在现代反垃圾邮件网关面前（特别是谷歌和雅虎发布强制 DMARC 新规后）几乎寸步难行。

四、阿里企业邮 vs CF别名转发深度对比#

为了更直观地看清两者的技术代差，我们把完整的链路细节进行深度对比：

维度	阿里企业邮箱（原生原生方案）	Gmail 别名 + CF 转发（拼装方案）
信体结构对齐 (Alignment)	完全对齐。Return-Path（信封）和 Header From（信头）都是你的域名 `jcaonet.com`。	无法对齐。信封经常是 `gmail.com` 或第三方代发平台域名，导致严重的域名对齐冲突。
DKIM 签名支持	原生完美支持。阿里出站服务器自动对邮件体进行强加密签名，公钥在你的 DNS 里。	极难配置或不支持。Gmail 别名客户端经常无法成功携带你自定义域名的纯正 DKIM。
IP 信誉 (Reputation)	极高。阿里企业邮拥有独立、受严格监管的企业级发信 IP 清单，很少被反垃圾组织拉黑。	极低或不稳定。别名代发如果走公共免费 SMTP，这些 IP 经常被发信耗子滥用，导致被连累进黑名单。
DMARC 兼容性	完美兼容。因为协议完全对齐，你可以安全地在 DNS 开启 `p=reject`（最高拒收策略）来防钓鱼。	极易翻车。一旦你的域名开启了严格的 DMARC 防御，你自己的别名发信经常会被对方服务器直接拒收。
收信转发环节 (Inbound)	直接收信。投递方直接连接阿里服务器，无中间商，不改变任何邮件头信息。	二次转发。别人发给 CF，CF 再转给 Gmail。此时 CF 变成了发信人，Gmail 去查原始发信方（如腾讯）的 SPF 发现没有包含 CF 的 IP。虽然有 SRS 技术缓解，但依然极易在入件时被误杀。

五、总结与选型建议#

你在 Cloudflare 里面加 SPF/DKIM 的思路完全正确，这也是玩转域名主权的基础。然而：

企业邮箱（原生端到端）： 它是完整的闭环服务。发信、收信、签名、IP 全套链路都在你域名的控制和背书下，生态完全对齐，因此在现代邮件网络中受信度最高。如果你的域名有刚性业务需求（如商务沟通、重要网站注册、客户通知），企业邮箱是唯一的选择。
别名转发方案（多重拼装）： 它是一个**“缝合车”**。你虽然在 CF 塞了钥匙（加了解析），但发动机（Gmail 客户端）和底盘（代发服务器）不是一家人，信息在多次跨平台转发和代发中，原有的安全凭证极易被“蹭掉”，从而被对方的防火墙拦截。它更适合作为个人极客低频折腾、收发非核心验证码的玩具。

2026年日本签证与在留资格手续费涨价

Wed, 27 May 2026 00:00:00 GMT

近期计划申请日本签证、更新在留资格或者准备冲刺“永住”（日本绿卡）的小伙伴们注意了！日本政府针对外国人的各项行政手续费正在迎来数十年来最大幅度的一次调整。

2026年3月10日，日本政府正式阁议通过了《出入国管理及难民认定法》（入管法）的修正案。本次修正案的核心举措之一，就是大幅度拉高各项在留手续费的“法定上限”。今天我们就来详细梳理一下，从旅游签证到永住，最新的费用标准和未来的变动趋势。

一、核心政策背景：为什么要涨价？#

日本现行的签证及在留手续费标准，很多都是自1978年（近50年前）确立以来就几乎没有变动过。随着近年来访日外国游客以及在日留学生、就职人员的数量呈爆发式增长，日本出入国在留管理厅的行政审查成本、系统维护成本及物价均大幅上升。

为了缓解“过度旅游”（Over-tourism）带来的财政压力，并落实“受益者负担”原则，日本政府决定参考欧美国家的收费标准，分阶段全面上调手续费。

二、 2026最新费用标准及“法定上限”调整#

需要明确的是，2026年3月的阁议决定是提高了法律规定的**“最高收费上限”**，而具体执行的实际金额（政令指定金额）预计将在2026年度内正式立法通过后分步实施。

以下是根据最新国会审议及出入国在留管理厅披露的最新费用趋势汇总：

1. 赴日观光/商务签证（海外使领馆申请）#

此前日本签证费在国际上普遍偏低，2026年起将逐步向欧美看齐。

现行费用：单次入境约 3,000 日元（国内代办约 145 元人民币）；多次入境约 6,000 日元。
最新动向：计划将单次入境签证手续费上调至最高 15,000 日元（约合现行的5倍）。

2. 在留资格更新与变更（日本境内入管局申请）#

这关乎所有在日留学生和就职员工（如“技术·人文知识·国际业务”签证持有者）。

现行实际费用：4,000 日元 ~ 6,000 日元（视窗口或线上申请而定）。
2026修正案法定上限：由原来的 1 万日元暴涨至 10 万日元。
根据在留期限的预估实际收费趋势：
- 在留期间为 3 个月以下：预计 10,000 日元左右
- 在留期间为 5 年：预计高达 70,000 日元左右

3. 永住许可申请（永久居留权）#

这是本次调整中涨幅最夸张、最受在日华人关注的一项。

现行实际费用：8,000 日元（许可通过时缴纳，上限 1 万日元）。
2026修正案法定上限：直接拉高至 30 万日元（翻了30倍）。
最新国会审议预估实际收费：通过时的印纸费预计将调整为 20 万日元左右。

三、新旧费用速查表#

为了让大家更直观地对比，以下整理了本次改革前后的费用对比表格：

手续类型	现行实际费用 (印纸代)	2026法案修正后「法定上限」	国会预计最终执行金额 (目安)
单次赴日签证	约 3,000 日元	-	约 15,000 日元
多次赴日签证	约 6,000 日元	-	待定（按比例上调）
在留资格变更/更新	4,000 ~ 6,000 日元	100,000 日元	10,000 ~ 70,000 日元 (视期限制)
永住许可申请	8,000 日元	300,000 日元	约 200,000 日元

注意：上述入管局手续费（如更新、永住）属于“成功报酬制”，即只有在申请通过、去入管局领新在留卡或永住签证时，才需要购买对应金额的“收入印纸”缴纳。如果被拒签，则不需要缴纳该法定手续费。

四、对在日华人及企业的后续影响#

多人口家庭的经济负担加重：如果是一家三口或四口人同时更新长期在留资格（如5年期签证），或者全家共同申请永住，未来单次的印纸费总额可能轻松突破 30 万到 50 万日元。
企业雇佣成本上升：对于大量依赖外国人 IT 人才或技能实习生/育成就劳者的日本企业来说，过去帮员工承担更新签证的费用只是“毛毛雨”，但未来几十号人同时更新将是一笔不小的财务开支。企业可能会重新评估人才留用成本。
倒逼审查速度与系统优化：日本律师联合会等组织也提出意见，认为既然手续费大幅向欧美看齐，入管局就必须解决目前永住审查动辄 10 个月到 1 年以上的低效现状，提升审批透明度。

五、总结与应对建议#

目前该《入管法改正案》正在日本国会进行紧密审议，预计将在 2026 年度内正式颁布并确定具体的施行日期。

给近期有计划的同学两点实用建议：

能早申就早申：如果你已经满足了永住申请条件（如普通就职满10年，或高度人才积分满70/80分），请务必尽早提交申请。只要在法规正式落地实施前通过审查或受理，大概率仍能享受旧制的低廉手续费。
关注在留期限分配：未来更新签证时，入管局给予的在留期限越长（比如1年变3年或5年），虽然单次缴费变高，但折算下来的平均年成本和折腾次数依然比年年更新划算，因此保持良好的纳税和社保记录以获取“长期在留”变得更加重要。

一键激活 JetBrains

Tue, 17 Mar 2026 00:00:00 GMT

无需手动下载文件、输入激活码，全自动扫描并激活 JetBrains 系列产品（IDEA 等）的最新方法。

IntelliJ IDEA 日文注释对齐问题完整排查记录

Fri, 13 Mar 2026 00:00:00 GMT

问题现象#

在编写 Java 文件时，文件头部常见的日文注释（变更履历）在さくらエディタ (Sakura Editor) 里对得整整齐齐：

1
/* 変更履歴
2
 * □□変更日□□□変更者□□□□変更概要
3
 * □□202X/0X/XX □□XXXX □□新規作成
4
 */

但一打开 IntelliJ IDEA，立刻错位得惨不忍睹：

*、□、日期、日文字符混在一起，第二行、第三行完全歪掉。
即使把主字体直接改成 MS Gothic（大小 15.0），重启 IDEA 后依然不对齐。

这是日文/中文开发者在 IDEA 里最常见的坑：全角字符宽度在不同渲染模式下不是严格的 2 倍半角，导致多行累积误差。

第一阶段：切换主字体为 MS Gothic（失败）#

尝试设置：

Settings → Editor → Font

Font: MS Gothic

Size: 15.0

Line height: 1.2

Fallback font: <None>

结果： 重启后仍然错位。

原因分析： MS Gothic 在 Subpixel 渲染下，全角实际宽度仍有微小浮动（1.98~2.02 倍），这种像素级的微调在长字符串下会导致严重的累积偏差。

第二阶段：发现 Antialiasing 设置（关键突破）#

设置位置：

Settings → Appearance & Behavior → Appearance → Antialiasing

IDE: Subpixel（保持）
Editor: Subpixel（默认） → 改为 Greyscale → Apply → 重启 IDEA

结果： 注释瞬间对齐，效果与 Sakura Editor 一致！

原理： Subpixel（次像素渲染）为了文字圆润会微调间距，对 CJK（中日韩）字符宽度有负面影响；Greyscale（灰度渲染）渲染更保守，强制像素级对齐。

第三阶段：换 Sarasa Mono（终极方案）#

虽然 Greyscale 解决了对齐，但英文看起来会略显模糊。为了兼顾“对齐”与“美观”，我们引入了更纱黑体 (Sarasa Gothic)。

下载 Sarasa Mono：GitHub Releases （建议选 TTF 版本）。
更新设置：
- Font: Sarasa Mono SC (或 Sarasa Mono J)
- Size: 15.0（或 14.0，视屏幕分辨率而定）
- Line height: 1.2
还原渲染设置：将 Editor Antialiasing 改回 Subpixel。

结果：

日文注释完美对齐：Sarasa 系列字体在设计上保证了全角严格等于 1:2 的半角宽度。
英文锐利好看：利用 Subpixel 提升了代码阅读的清晰度。
稳定性：跨平台显示一致。

最终推荐配置#

项目	设置值
Font	Sarasa Mono (更纱等宽黑体)
Size	14.0 ~ 15.0
Line height	1.2
Editor Antialiasing	Subpixel
Fallback font	`<None>`

总结#

解决 IDEA CJK 对齐问题的三步走：

测试：将 Editor Antialiasing 改为 Greyscale 确认是否为渲染引起。
根治：安装 Sarasa Mono，从字体层面强制 1:2 比例。
优化：切回 Subpixel 保证英文字符的视觉巅峰。

现在 IDEA 里的变更履历终于不再乱跳，强迫症表示非常舒适！

参考资料：Sarasa Gothic GitHub

Git 忽略已被跟踪文件的本地修改

Thu, 12 Mar 2026 00:00:00 GMT

场景描述#

在日常开发中，我们经常遇到这样的情况：

必须修改配置文件：为了在本地运行程序，不得不修改数据库连接或本地环境路径。
文件已被 Git 跟踪：这些文件已经在远程仓库中，直接添加 .gitignore 是无效的。
不想提交修改：你希望这些文件不出现在 Commit 列表中，避免误提交，但又希望文件能正常参与编译和运行。

核心方案：`assume-unchanged`#

Git 提供了一个 assume-unchanged 标志位，告诉 Git：“即使这个文件在本地被修改了，也请假装它没有变化”。

方法 1：使用 TortoiseGit 界面操作#

如果你习惯使用图形化界面：

在文件上右键 -> TortoiseGit -> 設定 (Settings)。
进入 コンテキストメニュー (Context Menu) 选项卡。
勾选 変化していないものとみなす (Assume unchanged)。
回到文件右键，即可看到该选项。点击后，文件图标的红色感叹号将消失。

方法 2：使用自动化脚本（推荐）#

对于需要批量处理多个文件或子目录的情况，使用批处理脚本（.bat）效率更高。

1. 批量忽略工具 (`GitHide.bat`)#

将以下代码保存为 .bat 文件。注意：在 Windows 环境下，请使用 ANSI (Shift-JIS) 编码保存，以防止日语或中文注释乱码。

Terminal window显示更多显示更少

1
@echo off
2
rem 项目根目录路径切换
3
cd /d "C:\Your\Project\Path"
4

5
echo 正在处理指定文件列表...
6

7
rem 批量忽略特定后缀的文件（递归子文件夹）
8
for /f "delims=" %%i in ('git ls-files "path/to/dir/*.xml"') do (
9
    git update-index --assume-unchanged "%%i"
10
)
11

12
rem 忽略特定的单个文件
13
git update-index --assume-unchanged "path/to/your/TargetFile.java"
14

15
echo ==========================================
16
echo 处理完毕！目前处于“隐藏”状态的文件：
17
git ls-files -v | findstr "^h"
18
echo ==========================================
19
pause

显示更多显示更少

2. 批量恢复工具 (`GitShow.bat`)#

当你需要拉取远程更新或正式提交这些文件时，需要恢复跟踪状态：

Terminal window

1
@echo off
2
cd /d "C:\Your\Project\Path"
3

4
echo 正在恢复所有被隐藏的文件状态...
5

6
for /f "tokens=2" %%i in ('git ls-files -v ^| findstr "^h"') do (
7
    git update-index --no-assume-unchanged "%%i"
8
    echo 已恢复: %%i
9
)
10

11
echo 所有文件已恢复正常。
12
pause

关键状态码说明#

你可以通过命令 git ls-files -v 查看文件的状态：

标记	含义
H	正常跟踪中（Cached）
h	已忽略本地修改（Assume-unchanged）
S	另一种忽略模式（Skip-worktree）

常见问题 (FAQ)#

1. 执行了忽略，但 `git pull` 报错怎么办？#

如果远程仓库更新了同一个文件，Git 会为了保护你的本地修改而终止 Pull。此时请先运行 GitShow.bat，执行 git stash 暂存修改，然后再 Pull，最后恢复状态。

2. 为什么 `.gitignore` 不起作用？#

.gitignore 只能忽略**未被跟踪（Untracked）**的文件。一旦文件曾经被 git add 过，就必须使用本文提到的 update-index 方法。

安全提醒：本文档仅限内部技术交流，请勿将包含具体业务路径的脚本上传至公共仓库。

使用 Loon 屏蔽 iOS 与 Apple Watch 更新提醒

Tue, 10 Mar 2026 00:00:00 GMT

为什么要屏蔽更新？#

苹果的更新推送机制非常“激进”。即便关闭了自动更新，系统依然会悄悄下载固件包并在设置图标上挂一个消不掉的红点。本文将通过 Loon 规则拦截 + 手动清理 + 描述文件 的三重手段，帮你找回清爽。

第一阶段：Loon 规则拦截#

在 Loon 中拦截检查更新的服务器域名，这是最核心的步骤。

1. 手动添加分流规则#

进入 「配置」 -> 「分流规则」，手动添加以下域名并设置为 REJECT：

mesu.apple.com
gdmf.apple.com
appldnld.apple.com
ns.itunes.apple.com

2. 配置文件快捷粘贴#

如果你习惯编辑 .conf 文件，请在 [Rule] 模块下加入：

--- 屏蔽 iOS 更新开始 ---#

DOMAIN,mesu.apple.com,REJECT DOMAIN,gdmf.apple.com,REJECT DOMAIN,appldnld.apple.com,REJECT DOMAIN,ns.itunes.apple.com,REJECT

--- 屏蔽 iOS 更新结束 ---#

第二阶段：清理已下载的缓存（消除红点）#

关键： 如果已经有红点，必须手动删除固件包，拦截规则才能生效。

1. 针对 iPhone#

前往设置 -> 通用 -> iPhone 存储空间。
找到形如 “iOS 1x.x” 的项目。
点击 “删除更新”。

2. 针对 Apple Watch#

在 iPhone 上打开 Watch App。
进入 我的手表 -> 通用 -> 存储空间。
找到 “软件更新” 并执行删除。

第三阶段：安装 tvOS 描述文件（终极防御）#

安装 tvOS Beta 描述文件可以让 iPhone 误以为自己是 Apple TV，从而永远找不到适用的 iOS 更新包。

在 Safari 中下载最新的 tvOS Beta Software Profile。
前往设置 -> 已下载的描述文件 安装并重启。

进阶提示：如何恢复？#

恢复更新： 在 Loon 中关闭上述 REJECT 规则，并移除 tvOS 描述文件即可。

GitHub 仓库同步与冲突解决

Mon, 09 Mar 2026 00:00:00 GMT

在 Fork 了一个开源项目并进行大量个性化定制后，原作者的更新往往会带来大量的合并冲突。本文记录了在 VS Code 环境下，如何同步上游仓库并手动解决冲突的完整流程。

1. 环境准备：添加上游仓库#

首先，需要让本地仓库知道“原作者”的存在。我们将其定义为 upstream。

Terminal window

1
# 添加原作者仓库地址
2
git remote add upstream [https://github.com/原作者用户名/项目名.git](https://github.com/原作者用户名/项目名.git)
3

4
# 确认远程分支状态
5
git remote -v

2. 获取更新与触发合并#

在确保本地修改已全部 commit 的前提下，拉取作者的最新代码：

Terminal window

1
# 获取上游所有分支更新
2
git fetch upstream
3

4
# 合并上游主分支到本地当前分支
5
git merge upstream/master

3. 手动解决冲突 (Merge Conflicts)#

当终端提示 Automatic merge failed 时，VS Code 会进入冲突处理模式。

核心术语辨析#

在 VS Code 的冲突编辑器中，请务必认清：

Current Change (当前更改)：是你自己在本地修改的代码。
Incoming Change (传入的更改)：是原作者更新的代码。

操作流#

建议点击右下角的 “Open in Merge Editor”。左侧为作者更新，右侧为你的定制，下方为最终结果。

4. 完成合并与推送#

解决所有冲突后，执行以下步骤：

暂存修改：点击侧边栏 Merge Changes 列表文件旁的 + 号。
提交合并：点击消息框上方的 Continue。
同步云端：点击左下角的 Sync Changes（即 git push）。

注意： 同步时显示的数字（如 100 ↑）代表本地领先于 GitHub 服务器的提交数，包含了自己的改动和合并进来的作者记录。

5. 构建测试#

合并后务必运行构建脚本，确保项目正常

快速定位并解除 Windows 系统中被程序锁定的文件

Thu, 05 Mar 2026 00:00:00 GMT

文件被占用怎么办？精准定位并解除“幕后黑手”#

当你尝试删除、移动或重命名文件，却弹出 “文件正在使用” 或 “操作无法完成，因为文件已在另一个程序中打开” 时，通常是因为某个进程持有了该文件的句柄。

以下是几种从系统自带工具到专业软件的解决方案。

方案一：使用系统自带“资源监视器”（免下载）#

这是最快的方法，适合不想安装任何额外软件的场景：

打开任务管理器：按下 Ctrl + Shift + Esc。
进入资源监视器：点击性能选项卡，点击底部的 打开资源监视器。
搜索句柄：
- 在“资源监视器”中点击 CPU 标签页。
- 找到 关联的句柄 搜索框。
- 输入被锁定的 文件名 或 文件夹名。
结束进程：下方会列出占用该文件的程序名，右键点击该进程选择 “结束进程” 即可。

方案二：使用 Microsoft PowerToys (官方推荐)#

如果你安装了微软官方的 PowerToys，可以使用其中的 File Locksmith（文件锁匠） 功能，这是目前最优雅的集成方案：

操作方式：在文件资源管理器中，右键点击被占用的文件。
功能：选择 “什么在占用此文件？”，系统会弹窗列出所有相关进程，并允许你直接在此处点击“结束任务”。

方案三：第三方专业工具#

如果上述方法无效，可以尝试这些专门处理“顽固占用”的小工具：

工具名称	特点	下载建议
LockHunter	界面直观，支持解锁后自动删除到回收站，防止误删。	个人首选
IObit Unlocker	支持强制解锁、强制删除，操作简单。	适合顽固文件
Handle (Sysinternals)	微软提供的命令行工具，适合开发者或极客使用。	命令行操作

方案四：命令行查询 (PowerShell)#

如果你偏爱终端操作，可以使用以下思路：

Terminal window

1
# 查找特定文件的占用情况（需管理员权限）
2
# 注意：此命令在某些环境下需要预先配置 openfiles /local on 并重启
3
openfiles /query /fo table | findstr "文件名"

拒绝底噪：自制 FT140-43 共模阻流圈及 NanoVNA 测试指南

Sat, 28 Feb 2026 00:00:00 GMT

在城市公寓的阳台玩 SDR 接收，最让人崩溃的莫过于满屏的底噪。家里的路由器、LED 灯、开关电源无时无刻不在散发着高频射频噪音。

很多时候，这些噪音并不是通过空气辐射到天线上的（走空路），而是顺着同轴电缆的金属外皮“爬”进接收机的（走陆路）。此时，同轴电缆的屏蔽层不知不觉中变成了一根巨大的室内接收天线。

为了斩断这条“噪音高速公路”，我们需要制作一个共模阻流圈（Common Mode Choke, 简称 CMC）。

核心材料#

磁环： 推荐使用 FT140-43。43 材质（Mix 43）的高频特性非常适合短波频段（HF，3MHz - 30MHz），能提供极佳的宽带阻抗。注意，它是软磁材料，本身并没有永磁吸力。
线材： 推荐使用特氟龙（PTFE）外皮的镀银同轴电缆（如 RG-316），或者耐高温的单股特氟龙线。这种线材耐弯折、绝缘性极好，非常适合在磁环上紧密缠绕。
接头与辅料： 优质 SMA 接头、热缩管、绝缘胶带（用于包边防刮）。

制作要点：圈数与绕法#

对于主打短波段的接收，在 FT140-43 上通常绕 8 到 15 圈 是一个甜点区。

误区扫盲： 圈数绝对不是越多越好！圈数过多会导致分布电容增大，高频阻抗会断崖式下跌，甚至引起磁芯饱和。
推荐绕法： 建议采用 W1JR 交叉绕法。将线圈平分为两半，中间交叉穿过磁环。这种绕法能最大程度拉开输入端和输出端的物理距离，降低高频寄生电容，从而拓宽阻流圈的有效工作频段。

绕好的共模扼流圈

核心环节：如何用 NanoVNA 正确测试阻流圈？#

做完之后，用万用表测直流电阻永远是 0 欧姆，这无法验证其高频阻流效果。我们需要请出 NanoVNA。

⚠️ 致命误区：千万别把阻流圈两头直接拧在 VNA 上！ 直接拧上去测的是差模插入损耗，由于内部芯线完好，测出来必然是一条平坦的 0dB 直线。我们要测的是外皮（屏蔽网）对共模噪音的阻挡能力。

NanoVNA 的“硬核”飞线测试法（测量 S21 共模衰减）#

如果你手里没有带鳄鱼夹的 SMA 测试线，可以用三根废弃的细导线（杜邦线或网线芯）进行“飞线”测试：

共地连接： 用第一根线，将 NanoVNA 的 CH0（输入）和 CH1（输出）端口的金属外螺纹短接在一起。
连接阻流圈输入： 用第二根线，一头紧紧缠在阻流圈一端 SMA 接头的外螺纹上，另一头轻轻插进 NanoVNA CH0 端口的中心孔。
连接阻流圈输出： 用第三根线，一头缠在阻流圈另一端 SMA 接头的外螺纹上，另一头插进 NanoVNA CH1 端口的中心孔。

“飞线”测试

如何看图表数据？#

在 NanoVNA 上设置扫描范围为 1MHz 到 30MHz，查看 Trace: S21 (LogMag)。

如果你的阻流圈制作成功，你会在屏幕上看到一条深深陷入负值区域的曲线：

-10dB：阻挡 90% 共模噪音。
-20dB：阻挡 99% 共模噪音（合格线）。
-30dB 及以下：阻挡 99.9% 以上共模噪音（优秀极品）。

FT140-43 的特性通常会让这条曲线显得比较平坦宽广，如果在整个短波段都能维持在 -30dB 到 -40dB 的区间，说明这是一个教科书级的完美阻流圈！

安装位置建议#

做好的阻流圈该接在哪里？这取决于你的应用场景：

纯接收（SDR 玩家）： 如果你只接 SDR 听信号，且家里电器干扰严重，建议把阻流圈接在尽量靠近 SDR 的这一端。这相当于给接收机戴上防毒面具，挡住室内几米长馈线吸附的近场噪音。
发射与阳台地网（电台玩家）： 如果你在阳台将天线地线接在金属栏杆上，务必将阻流圈接在天线馈电点（室外端）。这能防止发射时的射频电流顺着外皮跑进屋里咬手，同时把栏杆里的高频垃圾拒之门外。

插上它，打开你的 SDR 软件看看瀑布图吧，清爽的黑色底噪正在向你招手！

日本三级业余无线电（3アマ）获取指南：国家考试 vs JARD培训 + 免费练习网站推荐

Tue, 24 Feb 2026 00:00:00 GMT

日本三级业余无线电（3级）获取指南#

国家考试 vs JARD培训课程 + 免费练习网站推荐

日本的第三級业余无线电技士（简称3级） 是入门短波HF、允许CW（摩尔斯码）、功率更高的实用资格。如果你没有4级，也可以直接考3级。下面全面对比两种主流路径：直接国家考试（CBT） vs JARD养成课程，并附上免费练习资源。

1. 两种路径核心对比#

项目	直接国家考试（CBT）	JARD养成课程（eラーニング标准コース）	推荐场景
通过率	约75–82%（近年76–79%）	几乎100%（极少不合格）	JARD更稳
费用	只考试费 ≈5,400–5,700日元	培训费+申请费 ≈13,000–17,000日元	国家考试省钱
时间需求	自学刷题 20–50小时（平均30–40小时）	指导16小时，实际20–40小时（最快几天–1个月）	两者差不多，但JARD更结构化
学习形式	纯自学（过去题、书籍、网站）	线上视频+电子教材+章节练习+中间测试+结业考	JARD适合新手/忙人
摩尔斯码	需要理解常见符号（多选题，非听写）	系统内反复强化+语吕记忆，难度低	两者都简单
拿证速度	学完立即预约CBT → 当天出分	报名后第二天开始 → 3个月内完（实际1–2个月）	国家考试更快
考试形式	CBT电脑考，30题（法规15 + 工学15），60分钟	结业考CBT，法规10题 + 工学20题，合格率极高	—
知识深度	自己刷题，理解可能更深	重点划定，够用就行	国家考试更扎实

一句话总结：

想省钱 + 自己刷题不怕 → 直接国家考试。
想稳妥 + 几乎不挂 + 结构化学习 → JARD eラーニング（无4级也能报标准コース）。
实际大多数新人（尤其是上班族）选JARD，因为“花钱买安心”，通过率近100%。

2. 国家考试自学推荐资源（免费练习网站）#

国家考试是CBT方式，题库固定，重复率高。以下免费网站超级实用，能覆盖大部分题型：

日本无线协会官网 - 官方例题
网址：https://www.nichimu.or.jp/kshiken/siken/vcmsFolder_856/vcms_856.html
内容：官方PDF下载，包含第三級的例题（法规 + 工学各几组，带解答）。最权威，适合先熟悉题型。
提示：不是全过去题，但难度和格式一模一样。
edu-hakodate.jp クイズ系统
网址：https://www.edu-hakodate.jp/sasaki/cgi-bin/qqqsystem/index.cgi
内容：3级专用题库！
- 法规：315题
- 工学：262题
  模式：20问模拟考 / 胜ち抜き戦（错3题结束，刺激刷题）。
  特点：免费、无需注册、显示通过率和正确率统计。很多人刷这个 + 官方例题就过。
过去问ドットコム
网址：https://kakomonn.com/
内容：1问1答式过去题，支持手机/PC。搜索“第三級アマチュア無線技士”，有法规和工学题。
特点：可反复做、统计进度，免费。
Soft Taprix 3アマ問題集
网址：https://soft.taprix.org/web/mn2/ham3
内容：法规10套 + 工学8套的多选题在线练习。
特点：简单直接，适合快速热身。
其他补充
- drone-k.com/post-3878：约100道3级过去题网页版。
- YouTube搜索“3アマ過去問解説”：视频刷题（免费，边听边记）。

自学攻略：
每天1–2小时，先刷官方例题 → edu-hakodateクイズ系统反复做 → 配《アマチュア完全丸暗記 2026》重点背高频题。3–7天就能稳。

3. 最终建议#

预算紧 + 自律强 → 国家CBT + 以上免费网站。
时间宝贵 + 怕挂 → JARD eラーニング（官网：https://www.jard.or.jp/eln-center/3rd-class/3rd-class_guide.html），报名后视频+题库+结业考，几乎稳过。
目标玩CW（摩尔斯） → 必须3级以上，4级禁止CW。

SDR# 实用插件清单（含下载地址）

Tue, 17 Feb 2026 00:00:00 GMT

SDR# 实用插件清单（含下载地址）#

SDR#（SDRSharp）本身是一个轻量级 SDR 前端软件，默认功能偏基础。如果想扩展扫描、录制、数字语音解码、卫星接收等功能，就需要安装插件。

本文整理常用、实用的 SDR# 插件，并附下载来源与用途说明。

一、推荐：插件合集安装包#

SDR Chile Community Plugin Package#

这是目前最省事的插件集合包，一次安装多个常用插件。

下载地址： https://sdrchile.cl/en/

包含插件示例：

Audio Processor（音频处理）
Audio Recorder（音频录制）
Baseband Recorder（基带录制）
Frequency Scanner（频率扫描）
Frequency Manager（频率管理）
Meteor Demodulator（气象卫星解调）
DSD Interface（数字语音接口）
S-Meter（信号强度表）
UDP Audio Streaming

适合：想一次性装齐常用插件的人。

二、基础增强类插件#

1. ListenInfo Plugin#

用途：增强频率/台站信息显示，适合监听爱好者。

下载： https://github.com/BlackApple62/SDRSharp-ListenInfo-Plugin/

2. SDRSharp Plugin Manager#

用途：插件管理工具，简化插件启用和管理。

下载： https://github.com/slapec/SDRSharpPluginManager

三、频率扫描与管理类#

Frequency Scanner#

用途：自动扫描强信号频点。

通常包含在 SDR Chile 插件包内。

Frequency Manager#

用途：管理收藏频率，保存电台列表。

通常包含在插件合集内。

四、数字语音与解码类#

DSD Interface / DSDtcp#

用途：配合 DSD+ 使用，解码 DMR、P25、NXDN 等数字语音。

说明： SDR# 本身不带数字语音解码，需要外部 DSD+ 软件配合。

五、卫星与图像类#

Meteor Demodulator#

用途：解调气象卫星信号（如 Meteor-M 系列）。

通常包含在社区插件包内。

Orbitron Plugin（旧版）#

用途：与 Orbitron 联动进行卫星跟踪。

注意：部分版本可能已不兼容新版 SDR#。

六、记录与分析类#

Signal Strength Logger#

用途：记录信号强度变化。

RDS Logger#

用途：记录 FM 广播的 RDS 信息。

七、常见注意事项#

插件需匹配 SDR# 版本（x86 / x64）。
某些旧插件不兼容新版 .NET 版本。
安装步骤通常为：
- 下载插件 DLL
- 放入 SDR# 安装目录的 Plugins 文件夹
- 如有需要，编辑 Plugins.xml
- 重启 SDR#
建议不要混装不同版本插件。

八、关于数字模式（CW / FT8）#

SDR# 本身：

仅负责解调
不负责解码

如果需要：

CW 解码
FT8
PSK31

通常需要：

虚拟声卡（如 VB-Cable）
外部软件（WSJT-X / FLDIGI）

如果希望一体化体验，可以考虑使用 SDRangel。

九、总结#

如果你是：

频谱观察 / 广播监听 → SDR# + 插件足够
数字模式深度玩法 → 可能需要外部软件配合
想少折腾 → 建议直接安装 SDR Chile 插件合集

无线电爱好者监听指南：频率、波长与天线参考

Mon, 16 Feb 2026 00:00:00 GMT

📻 前言#

最近喜欢上了无线电，记录一下。

对于 SDR 玩家或刚入门的 HAM，理解频率与天线长度的关系是第一步。以下是计算公式参考：

波长 (λ\lambdaλ) = 300/f300 / f300/f (MHz)
1/4 波长天线长度 (米) ≈71.25/f\approx 71.25 / f≈71.25/f (MHz) (已考虑缩短系数 0.95)

📡 核心监听频段概览#

1. 业余无线电 (Amateur Radio)#

日本的业余频段与国际略有不同，以下是几个最活跃的频段：

频段名称	频率范围 (MHz)	波长	1/4波长天线长度	说明
40m 坡	7.000 - 7.200	~40m	约 10.18m	日本短波最热闹的频段，白天通联极多。
6m 坡	50.000 - 54.000	~6m	约 1.43m	著名的“魔术频段”，受电离层影响会有惊喜。
2m 坡	144.000 - 146.000	~2m	约 0.49m	本地 FM 通联主力。
70cm 坡	430.000 - 440.000	~70cm	约 0.16m	城市内穿透力强，手台党最爱。

2. 民用与生活频率 (Scanning)#

这些频率通常用于监听。

类别	频率参考 (MHz)	推荐天线	监听重点
航空无线 (Airband)	118.000 - 136.000	1/4波长 (约 57cm)	羽田/成田机场进场指令。川口上空常能听到。
特定小电力	422.050 - 422.300	综合天线	建筑工地、餐厅、附近的无线呼叫。
特定广播 (FM)	76.0 - 95.0	1/4波长 (约 85cm)	日本 FM 频段较低，普通海外收音机可能收不到。
铁路无线	150MHz / 300MHz 附近	垂直天线	JR 和私铁的行车调度（注意：日本正数字化，部分已加密）。

🛠️ 川口市特别关注频率#

由于我住在川口站附近，以下频率在阳台上应该会有不错的信号：

羽田机场管制 (APP/DEP)：
- 119.100 MHz / 126.000 MHz。川口位于进场航路下方，信号极强。
关东 AM 广播 (Wide FM 转发)：
- TBS Radio: 90.5 MHz
- 文化放送: 91.6 MHz
- 日本放送: 93.0 MHz
- 天线建议： 约 80cm 的拉杆天线即可清晰接收。
紧急防灾无线：
- 川口市行政防灾无线（通常在 60MHz 或 400MHz 频段）。可以在发生台风或地震时听到防灾广播。

📐 简易天线制作速查#

如果要在阳台上架设天线，可以尝试制作水平偶极天线 (Dipole)。

L(总长度)=143f (MHz)L (\text{总长度}) = \frac{143}{f \text{ (MHz)}}L(总长度)=f (MHz)143

注意： 建议在阳台内侧或使用吸盘支架固定，避免身体过分探出护栏。

🔗 延伸工具推荐#

Radio Garden - 在线全球电台（参考）
总务省电波利用网站 - 查询日本合规频率的权威出处。

西瓜卡(Suica)买不了全地铁定期券

Tue, 03 Feb 2026 00:00:00 GMT

最近拿西瓜卡（Suica），跑到东京地铁（Tokyo Metro）的自动售票机前，想买一张从家到公司的“全地铁”定期券。

结果无论怎么操作，机器都提示无法写入，或者根本不识别。

你是不是也遇到了这个问题？别急，这不是卡坏了，也不是机器故障，而是你触碰了日本交通系 IC 卡的“地盘规则”。

核心原因：发卡方的“地盘”意识#

虽然现在 Suica 和 PASMO 在日常刷卡进出站、便利店消费上几乎是完全通用的，但在**购买定期券（Commuter Pass）**这件事上，它们有着严格的界限。

简单来说，定期券必须由“主要使用线路”的发卡方发行。

Suica (西瓜卡)：由 JR 东日本 发行。
PASMO: 由 私铁、地铁巴士联盟（包括东京 Metro、都营地铁、东急、小田急等）发行。

这里的规则是：#

如果你的定期券路线完全是地铁/私铁（例如：新宿线 -> 东西线），必须使用 PASMO。JR 的 Suica 无法承载纯私铁/地铁的定期券信息。
如果你的定期券路线完全是 JR（例如：山手线 -> 中央线），必须使用 Suica。
例外情况（联络定期券）：如果你的路线是 JR + 地铁 的混合路线，通常 Suica 和 PASMO 都可以购买（这叫作“联络定期券”），因为两边都有份。

结论： 你的问题在于，你想在一张 JR 发行的卡（Suica）上，写入一张完全属于地铁公司（PASMO 地盘）的定期券，这是系统不支持的。

解决方案#

既然知道了原因，解决起来就很简单了。

方案一：实体卡用户（换卡）#

如果你坚持使用实体卡，你需要去地铁站的自动售票机或定期券售票处（Pink Machine），购买一张 PASMO 卡。

在购买定期券的过程中，机器会提示你是否持有 IC 卡。如果你只有 Suica，你需要选择“购买新卡（PASMO）”，然后将定期券信息写入这张新的 PASMO 卡中。

方案二：手机党（Apple Pay / Google Pay）#

现在大多数人都在使用手机刷卡。如果你用的是 iPhone 或 Android：

打开你的“钱包”App (Wallet)。
不要尝试在你现有的 Suica 上购买。
点击右上角的 + 号，选择 交通卡。
搜索并添加一张 PASMO。
通过 PASMO App 或者直接在钱包里，为这张 PASMO 购买地铁定期券。

注意：在手机上，你可以同时通过“快速交通卡”设置，根据需要切换使用 Suica 或 PASMO，但在过闸机时，必须确保你的定期券所在的由于那张卡被感应到。通常建议将存有定期券的那张卡设为“默认/快速交通卡”。

总结#

虽然 Suica 也就是“西瓜卡”名气最大，但在东京的纯地铁通勤圈里，PASMO 才是真正的王者。

路线只有地铁/私铁 👉 用 PASMO
路线只有 JR 👉 用 Suica
路线混合 👉 Suica 或 PASMO 均可

希望这篇文章能帮你省去在车站机器前抓狂的时间！

如果你觉得这篇文章有用，欢迎分享给身边刚来日本的朋友。

Proxmox VE 虚拟机死机、服务崩溃与性能卡顿的排查

Mon, 02 Feb 2026 00:00:00 GMT

作为 Home Server 玩家，最头疼的莫过于虚拟机（VM）毫无征兆地“死机”或服务不可用。

最近我的 Ubuntu 24.04 VM 经常出现以下怪象：

服务崩溃：VS Code Tunnel 和 Cloudflare Tunnel 频繁断连。
伪死机：SSH 连不上，但 PVE 显示运行中。
性能异常：Cockpit 管理后台登录极慢，点击登录后小主机风扇狂转，CPU 占用飙升。

经过一整套排查，我发现这不仅仅是软件问题，更涉及虚拟化配置和底层硬件节能策略。以下是完整的排查与修复流程。

第一阶段：案发现场还原 (Log Analysis)#

当 VM 疑似死机时，不要急着强制重启。如果还能通过 PVE 的 VNC 控制台进入，或者重启后，我们需要第一时间提取“遗言”。

1. 查看系统日志#

现代 Linux (Ubuntu/Debian/CentOS) 推荐使用 journalctl。

关键命令：查看上一次启动周期的最后 100 行日志

Terminal window

1
# -b -1 表示“上一次启动”（本次启动是 -b 0）
2
# -n 100 表示只看最后 100 行
3
# -e 表示跳转到末尾
4
journalctl -b -1 -n 100 -e

2. 识别关键错误#

在我的案例中，通过上述命令检查日志，在末尾发现了大量的 General Protection Fault (GPF) 报错：

Terminal window

1
Feb 02 07:36:54 ubuntu24 kernel: traps: code[102321] general protection fault ip:70c6be715729 sp:7fff2e24ac28 error:0
2
Feb 02 07:36:55 ubuntu24 systemd[102230]: code-tunnel.service: Main process exited, code=dumped, status=11/SEGV

分析：

现象：code-tunnel 进程发生了段错误 (Segmentation Fault)。
推测：在 PVE 环境下，应用层程序的 GPF 通常不是程序本身的 Bug，而是CPU 指令集不兼容或内存地址映射异常。

第二阶段：虚拟化层调优 (The PVE Fix)#

这是解决“莫名其妙崩溃”最核心的一步。默认的 PVE 设置为了兼容性（迁移方便），牺牲了性能和稳定性。

1. 修改 CPU 类型 (最重要的操作)#

PVE 创建 VM 时默认 CPU 类型是 kvm64。这是一个极其古老的虚拟 CPU 模型，缺失很多现代指令集（如 SSE4.2, AVX 等）。现代程序（Node.js, Go, Java）如果调用了这些指令，就会导致进程直接崩溃或报错。

操作路径：PVE 网页端 -> 选择 VM -> 硬件 (Hardware) -> 处理器 (Processors) -> 编辑。
修改项：将 类别 (Type) 从 kvm64 改为 host。
作用：将宿主机的真实 CPU 指令集透传给虚拟机。

2. 关闭内存气球 (Memory Ballooning)#

如果你的日志里没有报错，但系统偶尔卡顿，或者在服务启动瞬间崩溃，大概率是内存气球在作祟。

现象：PVE 显示内存用量如 8.00 GiB [balloon=0]。
原理：气球驱动会动态回收 VM 的内存给宿主机。当 VM 突然需要大量内存（如启动 Java 应用或 TLS 握手）时，如果分配不及时，会导致内核级错误。
操作：PVE -> VM -> 硬件 -> 内存 -> 取消勾选“高级”中的“内存气球设备 (Ballooning Device)”。

第三阶段：硬件层与 BIOS 调优 (C-States)#

这是解决“Cockpit 登录慢”、“风扇狂转”以及“闲置久了连不上”的关键。

1. 症状分析#

通过 htop 观察，当我尝试登录 Cockpit 时：

cockpit-tls 进程 CPU 占用率瞬间飙升至 100%。
物理机风扇开始起飞。
登录过程耗时 10-30 秒。

2. 罪魁祸首：CPU C-States#

小主机（N100/N305/i5-1240P 等）的 BIOS 默认开启深度节能（C6/C7）。

待机时：CPU 处于深度睡眠，频率极低。
唤醒时：当有请求（如 HTTPS 握手）进来，CPU 需要从 C6 状态“惊醒”并拉升电压。这个唤醒延迟 (Exit Latency) 导致了首包卡顿。而电压的剧烈波动，配合 PVE 的虚拟化层，极易触发 General Protection Fault。

3. 解决方案#

方案 A：BIOS 禁用（彻底解决） 进入 BIOS，找到 C-States 或 Power Management，将其设为 Disabled 或 High Performance。

方案 B：系统层锁频（不重启的折中方案） 在 PVE 宿主机（不是 VM）的 Shell 中执行：

Terminal window

1
# 将 CPU 调度器强制设为性能模式，禁止降频
2
echo "performance" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

代价：待机功耗可能会上升 5W-10W 左右，但换来了绝对的稳定性。

第四阶段：保底方案 (Watchdog Script)#

如果以上都做了，你还是担心隧道断连，可以写一个简单的看门狗脚本。思路是：检测业务连通性 -> 失败则重启服务 -> 再失败则重启 VM。

创建脚本 /usr/local/bin/tunnel_watchdog.sh：

1
#!/bin/bash
2

3
# 配置检测目标（建议用你的外部域名）
4
CHECK_URL="[https://your-domain.com](https://your-domain.com)"
5
LOG_FILE="/var/log/tunnel_reboot.log"
6

7
# 尝试检测 (超时时间 15秒)
8
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}" --max-time 15 "$CHECK_URL")
9

10
# 逻辑：只要不是 200 (成功) 或 401 (鉴权失败但连通)，就视为断网
11
if [[ "$HTTP_CODE" != "200" && "$HTTP_CODE" != "401" ]]; then
12
    echo "$(date): Tunnel Down (Code: $HTTP_CODE). 执行紧急重启!" >> $LOG_FILE
13
    sync
14
    /sbin/reboot -f
15
else
16
    echo "$(date): Tunnel 正常 (Code: $HTTP_CODE)" >> $LOG_FILE
17
fi

显示更多显示更少

添加定时任务 (sudo crontab -e)，每小时执行一次：

Terminal window

1
0 * * * * /usr/local/bin/tunnel_watchdog.sh

总结#

Home Server 的不稳定性通常遵循由软到硬的排查路径：

看日志：确认是应用崩溃 (SegFault) 还是内核崩溃 (Kernel Panic)。
改配置：PVE 虚拟机 CPU 务必选 host。
关节能：对于 24 小时运行的服务器，关闭 C-States 能解决绝大多数“由于闲置太久导致的奇怪问题”。

希望这篇指南能帮你的 HomeLab 找回久违的宁静。

Docker部署Waline评论系统 (SQLite版)

Sat, 17 Jan 2026 00:00:00 GMT

最近为了给博客增加评论功能，折腾了一下 Waline。虽然官方文档很全，但在实际的 Docker + SQLite + Cloudflare Tunnel 架构下，还是踩了不少坑。

特别是“数据库文件 0kb”和“无限密码错误”这两个问题，花了不少时间排查。这里记录一下完整的部署流程和避坑经验。

1. 为什么选择 Self-Hosted (Docker + SQLite)？#

虽然 Waline 提供了 Vercel 免费部署方案，但我最终选择了在自己的 Ubuntu 服务器上用 Docker 部署，原因有三：

响应速度：Vercel 免费版有冷启动延迟（3-5秒），而 Docker 常驻内存是毫秒级响应。
数据掌控：数据就在本地的一个 .sqlite 文件里，备份迁移极其方便，不用担心云服务商改政策。
隐私安全：所有数据都在自己的服务器闭环，不经过第三方。

2. 核心配置：Docker Compose#

这是经过修正后，完全可用的 docker-compose.yml。

目录结构#

Terminal window

1
~/docker/waline/
2
├── docker-compose.yml
3
└── data/            # 自动挂载的数据目录

配置文件 (docker-compose.yml)#

1
version: '3'
2

3
services:
4
  waline:
5
    image: lizheming/waline:latest
6
    container_name: waline
7
    restart: always
8
    ports:
9
      - "8360:8360"
10
    volumes:
11
      # 挂载数据目录
12
      - ./data:/app/data
13
    environment:
14
      # --- 数据库配置 (关键点) ---
15
      - SQLITE_PATH=/app/data/
16

17
      # --- 安全配置 ---
18
      # 建议使用单引号，防止特殊字符（如%）被Shell误读
19
      - JWT_TOKEN='Your_Long_Secure_Random_String_2026'
20

21
      # --- 基础配置 ---
22
      - TZ=Asia/Tokyo
23
      # 安全域名白名单
24
      # 只有来自这些域名的请求才会被允许，其他域名引用会报错
25
      - SECURE_DOMAINS=blog.jcao.me,localhost,127.0.0.1

显示更多显示更少

注意：启动命令为 docker-compose up -d。

3. 实战避坑：我遇到的那些奇葩问题#

坑位一：生成的 waline.sqlite 是 0kb，无法写入表#

现象：容器启动看似正常，但查看日志报错 SQLITE_ERROR: no such table: wl_Comment。检查本地 data 目录，发现 waline.sqlite 文件大小为 0kb。问AI，结果AI一直在说是数据库文件必须指定到具体的文件名，不能只写目录！【SQLITE_PATH=/app/data/waline.sqlite】

原因：被AI坑的极为惨烈，照着AI做的话无论如何都是会生成一个【waline.sqlite】文件夹而不是文件。

解决方法：

删除坏文件：手动删除那个 0kb 的文件或者文件夹。
Terminal window
```
1
sudo rm data/waline.sqlite
2
docker-compose down && docker-compose up -d
```
下载文件：必须直接去https://github.com/walinejs/waline/blob/main/assets/waline.sqlite下载waline.sqlite文件放入SQLITE_PATH里面

坑位二：换个网络/电脑登录，提示“密码错误”#

现象：在公司电脑注册好管理员账号，回家用家里电脑登录，死活提示密码错误。Waline 并没有 IP 锁定的功能，这很不科学。

原因：

JWT_TOKEN里面写了个【%】，特殊字符可能每次解析的结果不一致。
如果在 docker-compose.yml 里变量名写错（或者没写死），Waline 每次重启或在不同环境下可能会生成临时的 Key。
Key 变了，密码的哈希值就对不上了。

解决方法：确保JWT_TOKEN其值是一个固定的、用单引号包裹的字符串（防止 YAML 解析特殊字符）。

坑位三：403 Forbidden 与 Cloudflare 页面规则#

现象：由于使用了 Cloudflare Tunnel，为了防止别人直接访问后端首页，我在 Cloudflare 设置了页面重定向规则。结果导致博客前端发评论、更新头像时报 403 Forbidden。

原因：我的规则写成了 XXX.com*（带了星号），这把 API 请求（/api/comment）也给拦截重定向了。

正确的 Cloudflare Page Rule：

URL: XXX.com/ (注意末尾斜杠，且不要加星号)
Setting: Forwarding URL (301) -> https://blog.jcao.me/

坑位四：头像显示 “React blocked…” 或裂图#

现象：在个人资料里填入本地路径 /home/jcao/images/me.jpg，报错被拦截；填入 Pixiv 外链，显示裂图 (403)。

原因：

浏览器处于安全考虑，禁止网页直接读取本地硬盘文件。
Pixiv 等网站有防盗链机制，不允许第三方网站引用图片。

解决方法：将头像放在博客项目的 public/assets 目录下，部署后使用博客的公网 URL。

4. 总结#

虽然折腾了一下午，如果你也遇到了 0kb 数据库或者 403 报错，希望这篇文章能帮你节省几个小时的调试时间。

Proxmox VE (PVE)搭建

Thu, 15 Jan 2026 00:00:00 GMT

最近入手了一台小主机，打算折腾一个 HomeLab。首选的底层系统当然是 Proxmox VE (PVE)。相比于 ESXi，PVE 开源免费，基于 Debian，对新硬件的支持也更好。

这篇文章记录了我从零开始安装 PVE 8.x 以及部署第一台 Ubuntu Server 的全过程。

🛠️ 准备工作#

在开始之前，需要准备以下工具：

硬件：一台 x86 架构的小主机（建议至少 8GB 内存，双网口更佳）。
U 盘：8GB 以上，用于制作启动盘。
软件：
- Proxmox VE ISO 镜像 (下载最新版 VE 8.x ISO Installer)。
- Ventoy (推荐) 或 Rufus。
- Ubuntu Server ISO 镜像。

1. 制作启动盘#

强烈推荐使用 Ventoy。

下载并运行 Ventoy 安装程序，将 Ventoy 安装进 U 盘。
直接将下载好的 proxmox-ve_8.x-x.iso 文件复制到 U 盘里即可。

Tips: 以后如果想装 Windows 或 Ubuntu，只需要把 ISO 丢进去就行，不用反复格式化 U 盘。

2. BIOS 设置 (关键步骤)#

插入 U 盘，开机狂按 Del 或 F2 进入 BIOS。以下设置至关重要，否则可能导致安装失败或性能低下：

Virtualization (虚拟化): 必须开启 Intel VT-x / AMD-V。
VT-d / IOMMU: 建议开启（为以后直通网卡或显卡做准备）。
Secure Boot (安全启动): 必须关闭 (Disable)。PVE 的引导程序通常不支持安全启动。
Power Policy: 建议设置为 Always On（通电自启），作为服务器这是刚需。

设置完成后，保存重启，选择从 U 盘启动。

3. PVE 安装流程#

进入 Ventoy 界面后，选择 Proxmox VE ISO，然后选择 Install Proxmox VE (Graphical)。

3.1 核心配置步骤#

磁盘选择: Target Harddisk 选择你要安装系统的那块硬盘。
地区: Country 输入 China，Timezone 自动匹配。
密码: 设置 root 用户的密码，务必记住，这是登录 Web 管理后台的密码。

3.2 网络配置 (重中之重)#

这里必须设置一个 静态 IP (Static IP)，不能用 DHCP。

Management Interface: 选择主网口。
Hostname: 譬如 pve.local。
IP Address: 192.168.xx.xx (选一个固定的 IP，不要和家里其他设备冲突)。
Gateway: 路由器 IP。
DNS Server: 可以填路由器 IP，或者 114.114.114.114。

安装完成后拔掉 U 盘，机器会自动重启。

4. PVE 初始化与优化#

在同一局域网的电脑浏览器输入 https://你的PVE_IP:8006 登录。

4.1 换源 (去除企业订阅源)#

PVE 默认使用企业源，免费用户无法更新。在 PVE 的 Shell 中执行：

Terminal window

1
# 替换为清华源（以 PVE 8.x bookworm 为例）
2
sed -i 's|^deb [http://ftp.debian.org](http://ftp.debian.org)|deb [https://mirrors.tuna.tsinghua.edu.cn](https://mirrors.tuna.tsinghua.edu.cn)|g' /etc/apt/sources.list
3
sed -i 's|^deb [http://security.debian.org](http://security.debian.org)|deb [https://mirrors.tuna.tsinghua.edu.cn/debian-security](https://mirrors.tuna.tsinghua.edu.cn/debian-security)|g' /etc/apt/sources.list

5. 创建高性能虚拟机 (Ubuntu Server)#

这是最核心的部分，为了获得最佳性能，配置大有讲究。

上传 ISO: 在 local (pve) -> ISO Images 上传 Ubuntu Server 镜像。
创建 VM (Create VM)，注意以下关键参数：

选项卡	关键设置项	推荐值	原因
System	Machine	`q35`	较新的架构，PCIe 直通支持更好
System	BIOS	`OVMF (UEFI)`	现代 OS 推荐
System	Qemu Agent	开启 (Enable)	极重要！让 PVE 能获取 IP 和正确关机
Disks	Bus/Device	VirtIO Block	性能最好的半虚拟化驱动
CPU	Type	Host	直接透传物理 CPU 指令集，性能最强
Network	Model	VirtIO (paravirtualized)	网络性能最佳

6. Ubuntu Server 安装避坑#

启动虚拟机安装时：

用户设置: 不要直接用 root，创建一个普通用户（如 jcao）。
SSH: 务必勾选 [X] Install OpenSSH server。

⚠️ 常见报错：Failed unmounting cdrom#

安装完重启时，如果卡在 Failed unmounting cdrom：

回到 PVE 网页界面 -> 选中虚拟机 -> 硬件。
找到 CD/DVD Drive -> 编辑 -> 选择 “不使用任何介质”。
回到控制台按 Enter 即可。

7. 安全加固 (必做)#

服务器暴露在网络中，安全第一。

7.1 配置 SSH 密钥登录#

在本地电脑生成密钥并上传：

Terminal window

1
ssh-copy-id jcao@192.168.xx.xx

然后修改 /etc/ssh/sshd_config：

Terminal window

1
PasswordAuthentication no  # 禁止密码登录
2
PubkeyAuthentication yes   # 允许公钥登录

7.2 修改 SSH 端口与防火墙#

为了防扫描，建议修改 SSH 默认端口（例如改为 2333）。

修改配置: 编辑 /etc/ssh/sshd_config，设置 Port 2333。
重启服务 (Ubuntu 24.04 特有): 由于使用了 Socket 激活，必须重启 Socket 服务才能生效：
Terminal window
```
1
sudo systemctl daemon-reload
2
sudo systemctl restart ssh.socket
```

放行防火墙:

Terminal window

1
sudo ufw allow 2333/tcp
2
sudo ufw enable

7.3 安装 Fail2ban#

防爆破神器：

Terminal window

1
sudo apt install fail2ban
2
# 复制配置文件
3
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
4
# 重启服务
5
sudo systemctl restart fail2ban

至此，一台高性能、安全的 Linux 服务器就搭建完成了！

记忆转储

Logitech G502 X LIGHTSPEED 保修 RMA 全记录：滚轮故障到顺利换新

1. 故障现象与保修前准备#

2. RMA 申请沟通全过程#

阶段一：初次排查与提交申请（客服 Belle）#

阶段二：邮箱更正插曲与工单合并#

3. 结果与收尾#

4. 经验总结与避坑建议#

Git在push的时候防止出现Merge曲线的办法

为什么会出现这个 Merge 曲线？#

解决方案#

场景一：只在本地 Pull 了，还没有 Push 到服务器#

1. 撤销刚才的合并（回到 pull 前的状态）#

2. 使用 --rebase 重新拉取#

3. 正常推送#

场景二：Merge 曲线已经 Push 到了远程服务器#

1. 本地回退到 Merge 节点之前#

2. 重新用 Rebase 方式拉取#

3. 强行推送到远程覆盖历史#

常见顾虑：git pull --rebase 会覆盖别人的代码吗？#

一劳永逸：配置 Git 默认使用 Rebase#

iCloud 自定义域名邮箱 vs 传统企业邮箱

1. 原理与送达率：iCloud 是真正的邮箱还是仅仅转发？#

2. 核心区别对比#

3. iCloud 域名邮箱的独特优势#

4. 传统企业邮箱不可替代的地方#

5. 总结与选型建议#

博客统计从不蒜子迁移到 Vercount

起因#

Vercount 简介#

迁移步骤#

遇到的问题：数字变成了 1#

先找回原来的数字#

在 Vercount 后台修改数字#

为什么 Vercount 要验证，不蒜子不用#

需要留意的点#

总结#

如何安全地重命名 Git 分支（本地 + 远程）

一、核心原则#

二、命令行方式（推荐）#

1. 重命名本地分支#

2. 推送新分支到远程#

3. 删除远程旧分支#

4. 清理本地远程跟踪信息#

三、TortoiseGit（小乌龟）图形化操作#

1. 获取最新远程信息#

2. 切换到新分支#

3. 删除远程旧分支（可选）#

四、操作时的注意事项#

五、总结#

PVE 创建 LXC 容器全流程，以及它与 KVM 虚拟机的区别

一、先搞清楚 LXC 和 KVM 是什么#

二、创建 LXC 容器的完整流程#

1. 常规#

2. 模板#

3. 磁盘#

4. CPU#

5. 内存#

6. 网络#

7. DNS#

8. 确认#

三、命令行创建（可选）#

四、LXC 与 KVM 的核心区别#

1. 内存：上限 vs 向宿主机申请#

2. 内存可见性#

3. 热调整#

4. 隔离性与兼容性#

5. 资源占用与启动速度#

6. 备份与迁移#

五、怎么选？#

总结#

把 Waline 评论系统从本地 Docker 免费迁移到 Vercel + TiDB

先回答两个问题#

几个方案的对比#

迁移步骤#

1. 导出 SQLite 数据#

2. 在 TiDB Cloud 建库建表#

3. 导入数据（这里有个坑）#

4. 部署 Waline 到 Vercel（第二个坑）#

5. 配置环境变量（第三个、第四个坑）#

2. 使用 `--rebase` 重新拉取#

常见顾虑：`git pull --rebase` 会覆盖别人的代码吗？#