Posts

查看当前子模块 1 git submodule 输出类似： 1 a1b2c3d4 libs/foo (heads/main) 这里的 libs/foo 就是子模块路径。 也可以查看： 1 cat .gitmodules 输出类似： 1 2 3 [submodule "libs/foo"] path = libs/foo url = git@example.com:foo/bar.git 方法一：将 Submodule 转为普通目录(保留源码) 这种情况不直接删除目录，而是把子模块目录转换成普通目录。 Linux / macOS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ## 子模块目录 SUBMODULE=libs/foo ## 注销子模块 ## 会移除 .git/config 中的 submodule 配置 git submodule deinit -f "$SUBMODULE" ## 仅从 Git 索引中移除 ## 不删除本地代码 git rm --cached "$SUBMODULE" ## 删除 Git 对子模块的本地缓存 rm -rf ".git/modules/$SUBMODULE" ## 删除子模块目录内部的 Git 指向 ## 这里的 .git 可能是文件，也可能是目录 rm -rf "$SUBMODULE/.git" ## 重新作为普通目录加入 Git git add "$SUBMODULE" ## 提交变更 git commit -m "convert submodule to normal directory" Windows PowerShell 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ## 子模块目录 $SUBMODULE = "libs/foo" ## 注销子模块 ## 删除 .git/config 中的 submodule 信息 git submodule deinit -f $SUBMODULE ## 仅从 Git 索引中移除 ## 不删除本地代码 git rm --cached $SUBMODULE ## 删除 Git 对子模块的本地缓存 Remove-Item -Recurse -Force ".git/modules/$SUBMODULE" ## 删除子模块目录内部的 Git 指向 ## 这里的 .git 可能是文件，也可能是目录 Remove-Item -Recurse -Force "$SUBMODULE/.git" ## 重新添加为普通目录 git add $SUBMODULE ## 提交变更 git commit -m "convert submodule to normal directory" 方法二：删除 Submodule(不保留源码) Linux / macOS 下面命令仅需修改 SUBMODULE 字段。 ...

介绍 Mox Mail 是一个开源的邮件服务器解决方案，用于收发电子邮件。支持 IMAP4、SMTP、SPF、DKIM、DMARC、MTA-STS、DANE 和 DNSSEC，基于信誉和基于内容的垃圾邮件过滤，国际化（EIA/IDNA），使用 ACME 和 Let’s Encrypt 自动 TLS，帐户自动配置，网页邮件。 ...

最近申请了一张 U 卡，基于 USDC 进行充值，然后提现到 U 卡进行消费。这让我想起了 19 年挖过人人影视的 CVNT 币，当时也是可以闪兑成 ETH 的。 当时好奇 ETH 的原理，但没有现在学习这么方便（有 AI 加成），一直想搭建私链却没成功，后来在 ETH 的测试链上玩了一段时间（主要想体验一下转账、发币等）。现在各种开源工具非常丰富，技术也趋于成熟，所以决定自己搭建一个私链来研究一下。 其次的目的就是想学习区块链实战，例如如何让业务系统的关键数据上链，如：交易（hash）、文章防伪（hash）、存证（hash）等。 ...

背景 在自建Vaultwarden (Bitwarden) 时，数据库一般在服务器的某个目录下，肯定要每天备份防止密码数据丢失，我目前是采用rclone备份到腾讯云的对象储存(老用户有免费50G的容量)。今天无意间看见新方法，备份到github仓库，故进行实践。原文 ...

背景: 最近3个月左右，只要打开任意国外网站，那么间接性会出现 DNS 解析异常的问题，表现为网页无法打开，无法解析出域名。这时使用ping 则表现为 请求找不到主机 xxx。请检查该名称，然后重试。，但只要使用nslookup 后则可以正常解析域名，且浏览器也可以正常打开。 但因为这种情况时有时无，所以也就一直没有去深究这个问题，直到最近实在是受不了了，决定彻底解决这个问题。 ...

用了几年的Wordpress博客程序，直到现在，终于决定更换为Hugo了。期间也尝试过 typecho、halo、Hexo。 原因 性能问题：当然，作为文章不多(2年没更新)，每天的访问量“个位数”的博客，没资格说性能影响了。但我也使用了super cache缓存插件，屏蔽国外字体、图片等资源，总访问速度还是感觉挺慢的。(ps: 用腻WP了,想折腾了~) 当然服务器线路在国外，这是一个因素，性能倒不是问题(服务器配置)，毕竟跑在一台独立服务器上,由于没有启用别的服务，给wp的资源都是独享的。 在将博客迁移到OVH的服务器上后，使用itdog的网站测速(偷个懒，没有使用JMeter测试性能)，速度还不错，在启用super cache缓存插件的情况下， itdog访问情况如下 服务器资源占用 可以看出，并发访问时间，CPU占用率有点高，后面考虑换成静态博客。 选择Hugo的原因 在选择博客程序时，考虑了以下几个选项： typecho：没选typecho因为没有找到一款好看的主题，还特地花了几个小时将wp的数据库导入到typecho(利用Navicat将wp、typecho 数据表导出为excel，进行批量复制/修改，再导入typecho)，但怎么看也觉得别扭，后面想了想，都是动态博客还不如就保持wp，故放弃。 Hexo：则是因为感觉生成文章很慢，但不得不说，由于是nodejs生态，很多前端都参与了Hexo主题的开发，主题好看的都挺多的。 Halo：按理说这个系统我这个javaer应该挺合适的，但实际体验下来，总感觉后台操作体验怪怪的，有点像进业务系统的感觉，想着自己写博客就联想到了业务系统，故放弃。 Hugo：说到hugo，很早之前也尝试过，但当时觉得主题不丰富(其次是主题模板怪怪的，go语法不像php好看)，没有喜欢的主题，直到最近离职后，尝试学习Go语言，顺便又回头看了看Hugo，发现也就那么回事了，能“看懂”接受了，遂决定尝试一下。 迁移过程 迁移过程其实并不复杂，就是挺费时间的，主要步骤如下： 导出Wordpress内容：将 Wordpress 数据库导入到本地Mysql数据库。 转换格式：使用gemini-3-pro写了一个wp转md静态网页，将wp原文章，转换为Markdown格式，主要处理 标题、段落、列表、链接、图片、引用、代码块等常见WordPress元素。 设置Hugo：创建一个新的Hugo站点，选择 LoveIt 主题，并配置相应站点参数。 导入内容：将转换后的Markdown文件放入Hugo站点 的content目录中。 wp转md页面预览 未完成部分 评论迁移：目前评论还没迁移，后续考虑使用twikoo、waline、artalk等第三方评论系统, 估计使用artalk的可能性较大，因为也是go写的，性能应该不错。 域名: 目前博客域名使用的是 qyi.io，但io 每年都涨价几美元，我是19年注册的，当时35美元/年，现在已经涨到47.7美元/年(优惠后)，所以正在将.io切换为.com域名，保留几年io进行301跳转。 PS: 这io注册局越来越黑了。 自动化部署：目前是手动部署，后续考虑使用GitHub Actions / Drone 自动化部署。 结果 原博客 现博客

这篇文章是对 https://mp.weixin.qq.com/s/ih6hhTPTAgfT0L6MLObmqA 的学习，主要是针对 RocketMQ 积压大量消息的场景，分享一些排查思路和解决方案。 ...

最近因为个人需要(性价比还可以)，购买了一台OVH的KS-LE-C服务器，用于搭建一些测试环境和个人项目。 唯一缺点，硬盘不是NVME，而是SATA固态，但对于我的使用场景来说，影响不大。 购买过程 本意是想购买KS-LE-B的，但ovh提前进行了放货，并且由于很多人使用了OVH API 脚本挂着抢，导致KS-LE-B根本没见上货，这KS-LE-C还是原价从别人手里收的。 服务器配置 这台服务器的具体配置如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # # Yet-Another-Bench-Script # # v2025-04-20 # # https://github.com/masonr/yet-another-bench-script # # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## # Mon Nov 24 11:35:22 UTC 2025 Basic System Information: --------------------------------- Uptime : 0 days, 1 hours, 16 minutes Processor : Intel(R) Xeon(R) CPU E5-1630 v4 @ 3.70GHz CPU cores : 8 @ 1476.470 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 62.7 GiB Swap : 512.0 MiB Disk : 438.5 GiB Distro : Debian GNU/Linux 13 (trixie) Kernel : 6.12.57+deb13-amd64 VM Type : NONE IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : OVH SAS ASN : AS16276 OVH SAS Host : OVH SAS Location : Roubaix, Hauts-de-France (HDF) Country : France fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sdb3): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 132.32 MB/s (33.0k) | 170.26 MB/s (2.6k) Write | 132.67 MB/s (33.1k) | 171.15 MB/s (2.6k) Total | 264.99 MB/s (66.2k) | 341.41 MB/s (5.3k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 220.49 MB/s (430) | 227.37 MB/s (222) Write | 232.20 MB/s (453) | 242.52 MB/s (236) Total | 452.70 MB/s (883) | 469.89 MB/s (458) iperf3 Network Speed Tests (IPv4): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 496 Mbits/sec | 941 Mbits/sec | 3.81 ms Eranium | Amsterdam, NL (100G) | 494 Mbits/sec | 939 Mbits/sec | 9.07 ms Uztelecom | Tashkent, UZ (10G) | 444 Mbits/sec | 885 Mbits/sec | 96.7 ms Leaseweb | Singapore, SG (10G) | 398 Mbits/sec | 779 Mbits/sec | 164 ms Clouvider | Los Angeles, CA, US (10G) | 431 Mbits/sec | 844 Mbits/sec | 141 ms Leaseweb | NYC, NY, US (10G) | 422 Mbits/sec | 838 Mbits/sec | 78.0 ms Edgoo | Sao Paulo, BR (1G) | 409 Mbits/sec | 809 Mbits/sec | 203 ms iperf3 Network Speed Tests (IPv6): --------------------------------- Provider | Location (Link) | Send Speed | Recv Speed | Ping ----- | ----- | ---- | ---- | ---- Clouvider | London, UK (10G) | 489 Mbits/sec | 928 Mbits/sec | 6.28 ms Eranium | Amsterdam, NL (100G) | 487 Mbits/sec | 926 Mbits/sec | 9.04 ms Uztelecom | Tashkent, UZ (10G) | 458 Mbits/sec | 856 Mbits/sec | 96.7 ms Leaseweb | Singapore, SG (10G) | 399 Mbits/sec | 657 Mbits/sec | 164 ms Clouvider | Los Angeles, CA, US (10G) | 433 Mbits/sec | 841 Mbits/sec | 141 ms Leaseweb | NYC, NY, US (10G) | 437 Mbits/sec | 828 Mbits/sec | 77.9 ms Edgoo | Sao Paulo, BR (1G) | 380 Mbits/sec | 776 Mbits/sec | 202 ms Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 1364 Multi Core | 4854 Full Test | https://browser.geekbench.com/v6/cpu/15206739 YABS completed in 13 min 20 sec 单核测试分数：1098 多核测试分数：4505 详细结果链接：https://browser.geekbench.com/v5/cpu/23936424

本篇文章以MinIO作为文件服务端，其他基于S3协议的文件服务也一样。 通过接口返回文件地址给前端时，可以结合 S3 的预签名 URL 或 STS（临时凭证） 来实现安全访问。 核心思路 接口返回的文件地址不直接暴露 MinIO 存储路径。 在返回文件地址前，通过后端生成 预签名 URL 或 动态临时凭证。 前端使用该地址访问文件，确保文件访问受到权限和时间限制。 实现方法 1：基于预签名 URL 1.1 后端生成预签名 URL 使用 MinIO 提供的 SDK，在接口中动态生成带有时间限制的预签名 URL，并返回给前端。 Java 示例代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 import io.minio.MinioClient; import io.minio.GetPresignedObjectUrlArgs; import io.minio.http.Method; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; @RestController public class FileController { private final MinioClient minioClient; public FileController() { this.minioClient = MinioClient.builder() .endpoint("https://your-minio-server.com") .credentials("ACCESS_KEY", "SECRET_KEY") .build(); } @GetMapping("/api/getFileUrl") public String getFileUrl(@RequestParam String bucketName, @RequestParam String objectName) { try { // 生成预签名 URL（有效期 1 小时） String url = minioClient.getPresignedObjectUrl( GetPresignedObjectUrlArgs.builder() .method(Method.GET) .bucket(bucketName) .object(objectName) .expiry(60 * 60) // 有效期：1小时 .build() ); return url; } catch (Exception e) { e.printStackTrace(); return "Error generating URL"; } } } 1.2 接口返回示例 前端调用 /api/getFileUrl，后端返回： ...

当执行 docker login xxx.xxx.xxx 命令后，Docker 客户端会尝试登录到指定的镜像仓库 xxx.xxx.xxx，并提示输入用户名和密码（如果该仓库需要身份验证）。成功登录后，Docker 会将登录凭证存储在本地（通常在 ~/.docker/config.json 文件中），以便后续操作（如拉取镜像或推送镜像）可以自动使用这些凭证。 对拉取镜像的具体变化 执行 docker login xxx.xxx.xxx 后，拉取镜像时的变化取决于以下几个方面： 访问私有镜像 如果 xxx.xxx.xxx 是一个私有镜像仓库，并且之前没有登录，那么在登录之前尝试拉取该仓库中的私有镜像会失败（通常会收到 unauthorized: authentication required 的错误）。登录成功后，可以拉取该仓库中有权限访问的私有镜像。例如： 1 docker pull xxx.xxx.xxx/my-private-image:latest 在登录后，Docker 会使用存储的凭证自动完成身份验证，拉取过程会顺利进行。 加速镜像拉取（如果它是镜像代理） 如果 xxx.xxx.xxx 是一个镜像加速服务（类似于国内的镜像源，如阿里云、DaoCloud 等），登录后可能会影响从该仓库拉取镜像的速度。许多加速服务会代理 Docker Hub 的官方镜像，登录后可以通过该服务更快地下载镜像。例如： 1 docker pull xxx.xxx.xxx/library/ubuntu:latest 这里假设 xxx.xxx.xxx 代理了 Docker Hub 的 ubuntu 镜像，拉取速度可能会比直接从 registry-1.docker.io（Docker Hub 默认地址）更快，具体取决于网络环境和该服务的性能。 无变化的情况 如果登录后仍然拉取的是其他仓库的镜像（例如默认的 Docker Hub 镜像 ubuntu:latest），并且没有配置 xxx.xxx.xxx 作为镜像源，那么拉取镜像的行为不会有任何变化。登录仅对 xxx.xxx.xxx 仓库的操作生效。 拉取镜像的行为 在默认情况下，如果执行： 1 docker pull ubuntu:latest Docker 会从官方镜像仓库（即 Docker Hub，地址为 registry-1.docker.io）拉取 ubuntu:latest 镜像，而不是从 xxx.xxx.xxx 拉取。原因如下： ...