<meta name="baidu-site-verification" content="codeva-xxxxxxx"]]>
    
    
    2026-10-28T03:10:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      起因
sitemap 提交给 Google 之后一直显示「无法抓取」。用 Googlebot 的 UA 去取是 200，干脆把 225 条 URL 全跑一遍，揪出 8 条 404：
/404.html
/tags/Docker/   /tags/DOCKER/   /tags/Java/
/tags/kotlin/   /tags/python/   /tags/hexo/   /tags/nginx/
/404.html 是另一回事（nginx 里设成了 internal，本来就不该进 sitemap）。先说那 7 个标签页。
目录名对不上
对着服务器挨个查：
sitemap 写 Docker  → 服务器上是 docker
sitemap 写 Java    → 服务器上是 JAVA
sitemap 写 kotlin  → 服务器上是 Kotlin
每个都差一层大小写，而且新旧一一对应。
根子在文章的 front-matter。同一个东西，有的写 Docker，有的写 DOCKER，有的写 docker。Hexo 把它们当成三个不同的标签，生成三个目录。
三个目录在本地是同一个
因为我在 Windows 上写博客。
文件名不区分大小写，public/tags/Docker/ 和 public/tags/docker/ 指向同一块地方。构建时后生成的覆盖先生成的，最后只剩一种拼写，git 也就只记录了这一种。
扫了 92 篇、247 处标签引用，6 组冲突，改了 15 个文件 15 处，统一成首字母大写。
重新部署，还是 404
hexo clean 之后重建、hexo deploy，线上照样打不开 /tags/Docker/。
爬上去看目录，还是 DOCKER。
不是部署失败。.deploy_git 那个仓库的索引里记着旧路径 tags/DOCKER/index.html，新构建是 tags/Docker/index.html。Windows 上的 git 也认为这是同一个文件（core.ignorecase 默认开着），于是只更新内容，路径名一个字都没动。
改了大小写，但传不到 Linux 服务器上。
换一个干净的索引推
.deploy_git 是 hexo-deployer-git 自己维护的，没去碰它。直接拿构建产物新建一个仓库推上去：
D=$(mktemp -d)
cp -r public/. "$D"/
cd "$D"
git init -q && git add -A
git commit -q -m "deploy"
git push -f ubuntu@server:/var/repo/cykBlog.git HEAD:master
git init 出来是空索引，路径按实际大小写记录，推上去服务器就对了。
还有一步不能省
hexo clean。
不清的话 public/ 里旧的大小写目录还在，和新目录继续打架，谁覆盖谁看运气。
结果
7 个标签页恢复。sitemap 从 225 条降到 217 条——不是少了内容，是 6 组重复标签合并了。线上全量跑一遍，0 死链。
一个标签拼错三个写法，最后要动到 git 索引才能修好。这种东西不上线是发现不了的。
]]>
    
    https://cyk.pink/posts/1f975433.html
    
    2026-10-28T03:00:00.000Z
    

      起因
sitemap 提交给 Google 之后一直显示「无法抓取」。用 Googlebot 的 UA 去取是 200，干脆把 225 条 URL 全跑一遍，揪出 8 条 404：
/404.html
/tags/Docker/   /tags/DOCKER/   /tags/Java/
/tags/kotlin/   /tags/python/   /tags/hexo/   /tags/nginx/


/404.html]]>
    
    
    2026-10-28T03:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
      现象
www.cyk.pink 打不开，浏览器直接报证书错误。点「继续访问」之后又能看到完整站点。
先查再改
我一开始以为是 DNS 没做。查完发现想错了：
DNS        www.cyk.pink → 43.143.218.149       正常
80 端口     → 301 https://cyk.pink/            正常
443        server_name cyk.pink www.cyk.pink   两个域名同一个块
证书 SAN    DNS:cyk.pink                        没有 www
两个问题叠在一起：证书不认 www，443 又把 www 和主域塞进同一个 server 块。所以用户在证书警告页点继续之后，看到的是同一个站。
同一份内容挂在两个域名下，这才是要修的地方。
扩证书失败
sudo certbot --nginx -d cyk.pink -d www.cyk.pink --expand
Domain: www.cyk.pink
Detail: During secondary validation: Timeout during connect (likely firewall problem)
报错里写着 firewall，就去翻防火墙，80 和 443 对 0.0.0.0/0 全开。又换四个公共 DNS 查解析，也都正常。
Let’s Encrypt 现在是多节点校验，主节点过了、某个 secondary 节点超时也会判失败。跟我这边没关系。
换成 webroot，同时把 ACME 的验证路径从跳转里单独捞出来：
server {
    listen 80;
    server_name cyk.pink www.cyk.pink;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/cyk.pink;
        default_type "text/plain";
    }

    location / {
        return 301 https://cyk.pink$request_uri;
    }
}
这里踩了个坑。
80 端口原来是这么一句：
server {
    listen 80;
    server_name cyk.pink www.cyk.pink;
    return 301 https://cyk.pink$request_uri;
}
我直接在下面加了 location，以为能把验证路径拦下来。没拦住。
server 级的 return 在 rewrite 阶段就执行完了，根本轮不到 location 匹配。放行必须把跳转挪进 location / 里。
改完一次过：
sudo certbot certonly --webroot -w /var/www/cyk.pink \
  --cert-name cyk.pink -d cyk.pink -d www.cyk.pink --expand
443 拆成两块
主域的 server_name 只留裸域，www 单独一个块，只负责跳转：
server {
    listen 443 ssl http2;
    server_name www.cyk.pink;

    ssl_certificate     /etc/letsencrypt/live/cyk.pink/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/cyk.pink/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    return 301 https://cyk.pink$request_uri;
}
验证
https://www.cyk.pink/                 → 301 → https://cyk.pink/
https://www.cyk.pink/posts/xxx.html   → 301 → https://cyk.pink/posts/xxx.html
SAN: DNS:cyk.pink, DNS:www.cyk.pink
路径能带过去，不是一律回首页。
续期也验了一遍：certbot renew --dry-run 通过。签发方式自动改成 webroot 了，webroot_path 记在 renewal 配置里，以后不用再管。
]]>
    
    https://cyk.pink/posts/9f34c5bf.html
    
    2026-10-28T02:50:00.000Z
    

      现象
www.cyk.pink 打不开，浏览器直接报证书错误。点「继续访问」之后又能看到完整站点。
先查再改
我一开始以为是 DNS 没做。查完发现想错了：
DNS        www.cyk.pink → 43.143.218.149       正常
80 端口     → 301 https://cyk.pink/            正常
443]]>
    
    
    2026-10-28T02:50:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      起点
92 篇文章，site:cyk.pink 一条结果都没有。
不是排名差，是搜索引擎不知道有这么一个站。查了一下，sitemap、robots、feed 三个地址全是 404，站长平台一个都没提交过。三年里我做完 hexo deploy 就关浏览器。
先看已经有什么
免得重复劳动：
项目
结果
http → https
301
404 页面
真 404
canonical / og / article meta
有
gzip
开
sitemap / robots / feed
全 404
ld+json
无
站点描述
「我是CYK」
前三行是之前折腾 nginx 时顺手做好的，不用再碰。
sitemap 和 feed
npm i hexo-generator-sitemap hexo-generator-feed
sitemap:
  path: sitemap.xml
  tags: true
  categories: true

feed:
  type: atom
  path: atom.xml
  limit: 20
百度专用的 hexo-generator-baidu-sitemap 没装。那个包停在 Hexo 4 时代，装上直接跑不起来，而百度现在也读标准 sitemap。
生成完 225 条 URL。
robots.txt
User-agent: *
Allow: /

Sitemap: https://cyk.pink/sitemap.xml
Sitemap: https://cyk.pink/atom.xml
放在 source/ 根目录，构建时原样复制到站点根。
主题不输出 keywords
在 _config.yml 里配了 keywords，重新构建，页面里搜不到 <meta name="keywords">。翻主题 layout 才确认，Butterfly 压根没写这一行，配了等于没配。
Google 不看 keywords，百度和其他爬虫还读。既然要补，就从已经渲染好的 HTML 里把文章标签抠出来拼：
hexo.extend.filter.register('after_render:html', function (str) {
  if (/<meta name="keywords"/.test(str)) return str
  const tags = []
  const re = /<meta property="article:tag" content="([^"]*)"/g
  let m
  while ((m = re.exec(str)) !== null) tags.push(m[1])
  const kw = tags.length ? tags.join(',') : hexo.config.keywords
  return kw ? str.replace('</head>', `<meta name="keywords" content="${kw}">\n</head>`) : str
})
放 scripts/ 目录，hexo 启动时会自动加载。
结构化数据
主题里也没有 ld+json。没有它 Google 不给富摘要。
同一个 filter 接着写，一次输出四个类型：全站 WebSite + Person，文章页再加 BlogPosting 和 BreadcrumbList，用 @graph 串起来。
数据不用问 hexo 内部对象，从渲染好的 HTML 里反解更省事：
const url = pick(html, /<link rel="canonical" href="([^"]+)"/)
const isArticle = /<meta property="og:type" content="article"/.test(html)
两个地方要处理。
JSON.stringify 之后把 < 换成 \u003c。不换的话，文章正文里只要出现一次 </script>，整段脚本就提前闭合，后面全部错位。
整个 filter 包在 try/catch 里。SEO 脚本出问题最多是没加标签，不该让整个站构建失败。
285 个页面，284 个带上了，缺口是 404 页——它没有 canonical，被跳过了。
顺手清一条死链
主题自带一个 404 generator，会生成 /404.html，sitemap 插件把它当普通页面收了进去。但 nginx 里写着 location = /404.html { internal; }，外部访问必然 404。
一条不多，但没必要留着。
hexo.extend.filter.register('after_generate', clean)
hexo.extend.filter.register('after_exit', clean)
两个时机都挂，是因为它会和 sitemap 插件抢写入顺序。只挂 after_generate 的时候，加完文章重新生成，那个 /404.html 又被写回去了一次。
结果
sitemap 217 条，全量校验 0 死链，284/285 页有结构化数据。
真正的难点不在这几个配置，在于要先把「我以为的」和「实际缺的」分开——sitemap 和 ld+json 是真缺，其他都是瞎操心。
]]>
    
    https://cyk.pink/posts/6ec067b8.html
    
    2026-10-28T02:40:00.000Z
    

      起点
92 篇文章，site:cyk.pink 一条结果都没有。
不是排名差，是搜索引擎不知道有这么一个站。查了一下，sitemap、robots、feed 三个地址全是 404，站长平台一个都没提交过。三年里我做完 hexo deploy 就关浏览器。
先看已经有什么
免得重复劳动：



项目
结果



http → https
301


404 页面
真]]>
    
    
    2026-10-28T02:40:00.000Z
  
  
    
      CYK
    
    
    
    
    
      原来的样子
左上角三个圆点，右边一个大写加粗的语言名，还带一圈投影。做演示截图够用，放在正经文章里太吵。
highlight_theme: mac 关掉的只是配色，那三个圆点是写死在 CSS 里的。
圆点不是三个 div
是一个伪元素，用 box-shadow 投出来的：
#article-container figure.highlight .highlight-tools:after {
  position: absolute;
  left: 14px;
  width: 12px;
  height: 12px;
  border-radius: 50%;
  background: #fc625d;
  box-shadow: 20px 0 #fdbc40, 40px 0 #35cd4b;
  content: ' ';
}
一个红点靠 box-shadow 投出黄绿两个。所以关掉就是让它没有内容：
#article-container figure.highlight .highlight-tools:after {
  content: none;
}
语言标签的位置是写死的
.code-lang 是绝对定位，mac 模式下 left: 75px——正好给那三个圆点让位。圆点删了之后它还杵在 75px，得一起改。
顺手从 absolute 改成 static。工具条本来就是 flex，改完自然靠左，不用再算偏移：
#article-container figure.highlight .highlight-tools .code-lang {
  position: static;
  left: auto;
  padding-left: 9px;
  border-left: 2px solid #49b1f5;
  font-size: 12px;
  font-weight: 400;
  letter-spacing: .04em;
  text-transform: none;
  color: rgba(255,255,255,.42);
}
大写改回小写，去掉加粗，前面补一条短竖线。
卡片和工具条
#article-container figure.highlight {
  margin: 0 0 26px;
  border: 1px solid rgba(0,0,0,.06);
  border-radius: 10px;
  box-shadow: 0 1px 2px rgba(16,24,40,.04), 0 10px 24px -14px rgba(16,24,40,.15);
}

#article-container figure.highlight .highlight-tools {
  height: 34px;
  min-height: 34px;
  padding: 0 14px;
  background: transparent;
  border-bottom: 1px solid rgba(255,255,255,.07);
}
工具条背景透明，只留一条 1px 的分隔线。
底部那个 8px
pre 的 padding 我一开始上下都给 15px，结果每个块底部都空出一大截，怎么调都对不齐。
原因是 hexo 输出的每一行后面都跟一个 <br>，最后一行也不例外，等于凭空多了个空行：
<span class="line">docker search svn</span><br>
<span class="line"></span><br>
<span class="line">docker pull xxx</span><br>   ← 末尾这个
所以底部写 8px 就够了，多出来的空间是那个 <br> 撑的。
颜色不要跟主题走
主题的代码块底色在浅色和深色页面下都是深色（#212121 / #171717）。所以标签和按钮的文字颜色不能跟着页面主题走，否则浅色模式下变成深灰压深灰，基本看不见。
这两处我直接写死成浅色，只有卡片的边框和投影用了 [data-theme="dark"] 做区分。
放在哪
全部追加在 source/css/cyk.css 末尾，通过 _config.butterfly.yml 的 inject.head 引进来：
inject:
  head:
    - <link rel="stylesheet" href="/css/cyk.css" media="defer" onload="this.media='all'">
主题目录一个字没动，以后升级主题不会冲突。
]]>
    
    https://cyk.pink/posts/b303c1d5.html
    
    2026-10-28T02:30:00.000Z
    

      原来的样子
左上角三个圆点，右边一个大写加粗的语言名，还带一圈投影。做演示截图够用，放在正经文章里太吵。
highlight_theme: mac 关掉的只是配色，那三个圆点是写死在 CSS 里的。
圆点不是三个 div
是一个伪元素，用 box-shadow 投出来的：
#article-container 
    
    
    2026-10-28T02:30:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      现象
博客的评论区一直在转圈，一直以为是「没人评论所以空的」。
直到有一天为了查别的问题去调评论接口，发现请求根本没回来：
curl -X POST https://xxx.vercel.app/ → 超时
第一步：先看 DNS，别急着改代码
nslookup xxx.vercel.app
结果：
Addresses:  2a03:2880:f12c:183:face:b00c:0:25de
            31.13.85.2
face:b00c 是 Facebook 的 IPv6 特征段，31.13.x 也是 Facebook 的地址块。再查一个对照组：
nslookup vercel.com        → 64.239.123.1   ✅ 正常
nslookup test.vercel.app   → 208.43.170.231 + face:b00c  ❌ 同样被劫持
结论：***.vercel.app 整段被 DNS 污染**，解析结果全被指到 Facebook 的 IP 上，所以永远连不上。Vercel 本身没问题，vercel.com 是好的。
这也解释了为什么有些人抱怨「Vercel 上的服务国内打不开」——不是平台的问题，是域名被挡住了。
第二步：自定义域名能用，但有版本坑
我早先给评论服务绑过一个自定义域（twikoo.xxx.com，CNAME 到 Vercel 的 DNS），这个域名没被污染，200 正常响应。
但调接口返回：
{"code":1001,"message":"请更新 Twikoo 云函数至最新版本"}
按字面意思，应该去升级后端。于是我把后端镜像从头到尾换了几个版本——升到最新还是 1001。
回头看源码才发现，这句文案是误导的：
// @twikoojs/common
EVENT_NOT_EXIST: 1001,
1001 的真实含义是「事件不存在」。
这就对上了：前端加载的是 1.6.x，发的是 GET_COMMENTS 事件；后端早就是 2.x，事件名变了，直接不认。而提示文案还留在旧版本那句话上。
验证方法：换成不涉及事件名的接口试试：
GET_CONFIG            → 正常返回配置
GET_RECENT_COMMENTS   → 正常返回评论数据
GET_COMMENTS          → 1001
配置能读、数据能读，只有那一个事件不通——根本不是版本太旧，是前后端事件名对不上。
第三步：干脆搬回自己机器
既然域名被污染、版本又纠缠，索性不再依赖 Vercel。自己的服务器上跑一个容器就行：
docker run -d --name twikoo \
  --restart unless-stopped \
  --env-file /root/twikoo.env \
  -p 127.0.0.1:8082:8080 \
  -v /mydata/twikoo/data:/app/data \
  imaegoo/twikoo:latest
几个要点：
**只监听 127.0.0.1**，公网访问一律走 nginx 反代
数据库连接串放在 --env-file 里，文件权限 600，不要写在命令行（会进 shell history）
数据库还是用原来的 MongoDB Atlas，历史评论不用迁，连上就能读
/root/twikoo.env：
MONGODB_URI=mongodb+srv://用户:密码@集群/?retryWrites=true&w=majority
TWIKOO_THROTTLE=1000
第四步：nginx 反代到一个路径
不想再折腾子域名和证书，直接挂在主域名的路径下：
location ^~ /api/twikoo {
    rewrite ^/api/twikoo/?(.*)$ /$1 break;
    proxy_pass http://127.0.0.1:8082;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}
rewrite ... break 那行是关键：容器的接口在根路径 / 上，请求进来是 /api/twikoo，必须把前缀削掉再转发，否则容器收到 /api/twikoo 会 404。
博客配置改成：
twikoo:
  envId: https://你的域名/api/twikoo
好处是：不用动 DNS、不用单独申请证书，主域名有什么配置它就用什么。
第五步：前端也得是 2.x
后端换好了，前端还停在 1.6.x，照样不通。但直接改版本号会撞墙：
https://cdn.staticfile.org/twikoo/2.0.17/twikoo.all.min.js  → 404
https://cdn.staticfile.org/twikoo/1.6.31/twikoo.all.min.js  → 200
国内 CDN 只同步到 1.6.31，jsdelivr 这边又连不上。绕开的办法是从国内 npm 镜像把包下下来，放到自己站点里：
curl -o source/js/twikoo.all.min.js \
  "https://registry.npmmirror.com/twikoo/2.0.17/files/dist/twikoo.all.min.js"
然后在主题配置里覆盖这个脚本的地址（Butterfly 支持逐个插件指定 URL）：
CDN:
  option:
    twikoo: /js/twikoo.all.min.js
顺带的好处：评论系统不再依赖任何外部 CDN，外部 CDN 出问题、域名被墙，跟我没关系了。
结果
项目
之前
现在
评论接口
*.vercel.app，国内不通
自己的域名/api/twikoo
前端脚本
第三方 CDN 1.6.x
本站托管 2.0.x
数据
Atlas
Atlas（不变，直接沿用）
部署平台
Vercel
自己的 Docker
历史评论一条没丢——数据一直在数据库里，之前只是「接口调不通」，不是「数据没了」。
复盘
这次真正花时间的不是部署，是被错误提示带偏。「请更新云函数」这句话让我在后端版本上兜了好几圈，而真实原因（事件名变了）藏在源码的一个常量定义里。
遇到报错，尤其是第三方封装过的报错，先去查错误码的真实定义，别信文案。
]]>
    
    https://cyk.pink/posts/5e83b06a.html
    
    2026-10-27T07:20:00.000Z
    

      现象
博客的评论区一直在转圈，一直以为是「没人评论所以空的」。
直到有一天为了查别的问题去调评论接口，发现请求根本没回来：
curl -X POST https://xxx.vercel.app/ → 超时


第一步：先看 DNS，别急着改代码

    
    
    2026-10-27T07:20:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      先量化，再优化
重装之后顺手给站点做了一次体检，四个数字最扎眼：
指标
数值
HTTPS
只有 HTTP/1.1
gzip
只压 HTML，CSS/JS 全裸奔
图片缓存头
没有
图床里没人引用的死图
40 个，占 6.5MB / 8.9MB
前三个都是 nginx 一行配置的事，最后一个是长期积累的垃圾。
HTTP/2：一个连接跑完所有资源
HTTP/1.1 的问题是「一个连接同时只能处理一个请求」，浏览器只能靠开 6 个并发连接硬堆。页面有几十个资源的时候，排队是实打实的延迟。
开启只需要在 listen 后面加一个词：
listen 443 ssl http2;
验证别只看配置，要实际协商：
echo | openssl s_client -connect 127.0.0.1:443 -servername 你的域名 -alpn h2 2>/dev/null \
  | grep -i "ALPN protocol"
看到 ALPN protocol: h2 才算真的开了。
gzip：默认只压 HTML
这是最容易忽略的一项。nginx 的 gzip on; 打开之后，gzip_types 的**默认值只有 text/html**——CSS、JS、JSON、XML 一个都不压。
Ubuntu 的默认配置里这一行是注释掉的，很多人以为开了 gzip 就万事大吉：
gzip on;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml application/json application/javascript
           application/xml application/xml+rss image/svg+xml;
验证：
curl -s -o /dev/null -H "Accept-Encoding: gzip" \
  -w "%{size_download} bytes\n" https://你的域名/css/xxx.css
curl -sI -H "Accept-Encoding: gzip" https://你的域名/css/xxx.css | grep -i content-encoding
我这个站上的 CSS 压完大概剩三成。
缓存头：让重复访问变成零请求
图片走 nginx 反代到对象存储，响应里只有 ETag 和 Last-Modified，没有 Cache-Control——意味着浏览器每次都要回源确认一遍。图多的页面，读者翻两页就能感觉到。
location ^~ /cykblog/ {
    proxy_pass http://127.0.0.1:9000;
    add_header Cache-Control "public, max-age=2592000";
}
静态资源同理：
location ~* \.(?:css|js|jpg|jpeg|png|gif|webp|svg|ico|woff2?|ttf|eot)$ {
    expires 30d;
    add_header Cache-Control "public";
    try_files $uri =404;
}
注意一个 add_header 的坑：location 里一旦写了 add_header，server 层的 add_header 就不再继承。所以安全响应头要在每个自己写了 header 的 location 里重复一遍，否则 /cykblog/ 会漏掉。
server_tokens 和安全头
server_tokens off;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=2592000" always;
关掉版本号不是为了「安全多少」，是为了别主动告诉扫描器「我是 nginx 1.24.0，你可以去查这个版本的 CVE」。
HSTS 我一开始只给了 30 天，没设 preload。这个头一旦下发，浏览器在有效期内会强制走 HTTPS——证书出问题时网站会直接打不开，所以先短后长比较稳。
第三方 CDN 的两个教训
第一个：图标字体加载失败。 页面里引用了一个国内 CDN 的 iconfont，报 net::ERR_CONNECTION_CLOSED。在服务器上直接抓那个文件是 200，说明 CDN 本身没问题，是我本地到它的链路被掐了。
解决办法不是换 CDN，是把字体搬到自己的域名下：
curl -o iconfont.css "https://原CDN/iconfont.css"
curl -o iconfont.woff2 "https://原CDN/iconfont.woff2"
CSS 里用的是相对路径（url('iconfont.woff2')），放同一个目录就能自动找到，不用改。
第二个：统计脚本报 ERR_BLOCKED_BY_ORB。 一个免费访问量统计服务，请求失败后还会挂两分钟才超时，直接把首屏拖慢。关掉，换成 Cloudflare 的 Web Analytics（无 cookie、脚本小、国内可达）。
图床清理：40 个死图占 73% 空间
把桶里所有对象和「页面里实际引用到的」做了一次差集，结果很难看：
对象总数 80，被引用 51，无人引用 40，占用 6.5MB / 8.9MB
最大的一个是一张 2560×1440 的 PNG 壁纸，4MB——而且同一张图我早就转过 webp（104KB），只是忘了删 PNG，也没在用。
清理时踩了一个坑：用文件名直接 grep HTML 会漏。中文名和带反引号的文件名在 HTML 里是 URL 编码的：
磁盘：`scroll-view`滑动布局.webp
HTML：%60scroll-view%60%E6%BB%91%E5%8A%A8%E5%B8%83%E5%B1%80.webp
第一次按文件名匹配，把它们当成「无人引用」删了，结果 12 张正在用的图直接 404。还好删之前打了包，全部恢复。
正确的做法是先解码再比对，而且要同时扫 html / css / js 三类文件：
for m in re.findall(r'cykblog/([^"\'\s)<>?#]+)', txt):
    refs.add(urllib.parse.unquote(m))
改完之后桶从 8.9MB 降到 3.0MB，引用完整性校验为 0 缺失。
上传链路：把规范写进工具
以前传图是「拖进去就完事」，于是文件名长这样：
image-20240729225711008.png
wallhaven-6d61g4_2560x1440.png
`swiper`纵向轮播1.webp
现在用 PicGo 传，把规则配死：
路径：posts/{年}/{月}/（对象存储里的目录）
文件名：{y}{m}{d}-{rand:6}，例如 20261027-a3f9c2.webp
有个细节值得记一下：PicGo 的 MinIO 插件里，pathFormat 只支持 {bucket} 一个占位符，**不支持 {年}/{月}**。如果照着别的插件文档填，最后会生成一个字面量路径 posts/{年}/{月}/，对象存的路径和返回的 URL 对不上，图片必然 404。
效果
改动都不大，但叠加起来：
资源请求从「串行排队」变成「一个连接并发」
CSS/JS 传输量降到三成左右
重复访问的图片基本不再回源
图床体积减少 66%
首屏少了一个会挂两分钟的第三方请求
都是教科书里的东西，只是以前觉得「博客而已，无所谓」。
]]>
    
    https://cyk.pink/posts/9a1c47d2.html
    
    2026-10-27T03:50:00.000Z
    

      先量化，再优化
重装之后顺手给站点做了一次体检，四个数字最扎眼：



指标
数值



HTTPS
只有 HTTP/1.1


gzip
只压 HTML，CSS/JS 全裸奔


图片缓存头
没有


图床里没人引用的死图
40 个，占 6.5MB / 8.9MB


前三个都是 nginx 一行配置的事，最后一个是长期积累的垃圾。

    
    
    2026-10-27T03:50:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
    
      重装之后的第一件事不是装软件
系统重装完，ssh root@ip 一通，密码进去——这一步就已经错了。
上一台机器出事，本质就是「密码可以被人猜」。所以这次第一件事是：把密码登录这条路彻底关掉，改成密钥。
SSH 换密钥
本地生成一对 ed25519（比 RSA 短、比 RSA 快、强度还更高）：
ssh-keygen -t ed25519 -f ~/.ssh/cyk_server -N ""
把公钥追加到服务器的 ~/.ssh/authorized_keys，权限必须是这套：
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
然后写一份加固配置，放在 sshd_config.d/ 下（注意文件名要排在云厂商的默认配置前面，因为 sshd 是「先读到的生效」）：
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
MaxAuthTries 3
prohibit-password 的意思不是「允许 root 用密码」，而是「root 只能用密钥」——等于把 root 远程登录变相禁掉了。
改完先 sshd -t 验证语法，再 reload。验证前不要关当前窗口，不然配错了就真的进不去了。
现在登录长这样：
ssh cyk-server
.ssh/config 里配好别名，不用记 IP、不用带 -i。
端口从 12 个砍到 3 个
老机器上开了一堆端口：MySQL、Redis、Nacos、MinIO 控制台……每个都是当年「临时测一下」留下的。
新机器只留：
端口
用途
22
SSH
80
HTTP（301 跳 HTTPS）
443
HTTPS
图床的 9000 和 9090 全部改成只监听 127.0.0.1，需要的时候用 SSH 隧道临时打开：
ssh -L 9000:127.0.0.1:9000 -L 9090:127.0.0.1:9090 ubuntu@ip -N
隧道比开放端口好在：它要求先有 SSH 密钥。开端口是「对全世界开一扇门」，隧道是「拿着钥匙才给你开」。
fail2ban
老机器被打了 4466 次，一次告警都没有。这次装上：
apt install fail2ban
默认策略是「10 分钟内失败 5 次封 10 分钟」——10 分钟太短了，换个时间再来就跟没封一样。改成封一天：
# /etc/fail2ban/jail.local
[DEFAULT]
bantime = 86400
findtime = 600
maxretry = 5
有个副作用要记住：自己输错 5 次也会被封一天。被 DROP 掉的表现是「连接超时」而不是「拒绝连接」，很容易误判成网络问题。解封：
fail2ban-client set sshd unbanip 你的IP
服务不再直接对外
图床（MinIO）收到内网，对外只通过 nginx 反代一个路径：
location ^~ /cykblog/ {
    proxy_pass http://127.0.0.1:9000;
    add_header Cache-Control "public, max-age=2592000";
    proxy_set_header Host $host;
}
这里有个坑：前缀 location 必须写 ^~。否则下面那条「静态资源后缀」的正则 location 会优先匹配，把 /cykblog/xxx.webp 当成磁盘文件去找，直接 404。
文件管理（FileBrowser）也收到内网，但因为它有网页界面、还要长期对外，所以在 nginx 前面又加了一道 Basic Auth：
location ^~ /files/ {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:8081;
}
密码文件用 openssl 直接生成，不用额外装包：
printf 'user:%s\n' "$(openssl passwd -apr1 '你的密码')" > /etc/nginx/.htpasswd
现在访问 /files/ 是两层：先进 nginx 的认证，再进 FileBrowser 自己的登录页。这套软件官方已经停止维护了，多一层能挡住「拿已知漏洞直接打」的自动化扫描。
证书
Let’s Encrypt，certbot 自动续期，90 天一轮。装完确认一下定时任务在：
systemctl list-timers | grep certbot
一个反直觉的点
加固做完之后，日常使用几乎没有变麻烦：
SSH 还是敲一句，只是不用输密码了
图床上传还是拖文件，只是先开个隧道（或者用 PicGo 配好一次）
网页访问完全没区别
真正变麻烦的只有一件事：换新设备的时候要加一次公钥。三十秒的事。
反过来想，那台老机器省下的这三十秒，代价是两周的 root 权限在别人手里。
]]>
    
    https://cyk.pink/posts/3d5f8b17.html
    
    2026-10-27T01:20:00.000Z
    

      重装之后的第一件事不是装软件
系统重装完，ssh root@ip 一通，密码进去——这一步就已经错了。
上一台机器出事，本质就是「密码可以被人猜」。所以这次第一件事是：把密码登录这条路彻底关掉，改成密钥。
SSH 换密钥
本地生成一对 ed25519（比 RSA 短、比 RSA 快、强度还更高）：
ssh-keygen -t]]>
    
    
    2026-10-27T01:20:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      起因
一直挺得意那台轻量服务器——2 核 4G，跑着博客、图床、一个文件管理，两年没出过事。
10 月 26 号晚上翻图床的时候发现不对劲：桶里多了几个从来没上传过的文件，名字是 shell.php、.htaccess，还有一个叫 ahk_probe 的东西。第一反应是自己手滑，第二反应是——我根本没开过 PHP。
往下挖
先看的不是网站，是进程。
ps auxf | grep -v '\[' 
排在最上面的几个进程看着很正常，名字是系统自带的那种。但路径不对：
/dev/shm/.collector/collector.d
/dev/shm 是内存盘，重启就清空，正常服务不会往这儿放东西。collector.d 这个名字起得很「正经」，伪装成日志收集器——这种命名习惯不是随手写的，是有人专门研究过怎么不被人一眼看出来。
再看 /root/.ssh/，authorized_keys 里多了一把不属于我的公钥。也就是说：对方不需要密码也能随时回来。
溯源：入口在哪
翻 nginx 和 MinIO 的日志，链条很清楚：
图床的 9000 端口直接对着公网开着
MinIO 用的是默认凭据 minioadmin / minioadmin（建的时候图省事，一直没改）
对方扫到 9000，用默认口令直接进来了
通过 MinIO 的写入权限往桶里丢 web shell 和探测脚本
拿到执行权限后提权、装后门、留公钥
整个过程没有任何「高难度操作」。用的是出厂默认密码和不必要对外开放的端口。
顺带在 auth.log 里翻了 SSH 爆破记录，三个来源，都是同一批端口、同一套字典：
来源地址
归属
行为
51.222.47.156
境外（OVH 地址段）
单 IP 尝试登录 4466 次
106.53.117.97
中国·广东·广州（腾讯云）
扫描同一批端口
182.134.27.185
中国·四川·宜宾（电信）
扫描同一批端口
没什么好洗的，就是三个贱人：
51.222.47.156（境外 OVH 段）—— 一个 IP 硬试了 4466 次
106.53.117.97（广东广州，腾讯云）
182.134.27.185（四川宜宾，电信）
租台云主机来扫端口是贱人，拿别人的机器当跳板更是贱人。这三个地址我记在这儿了，哪天想起来了就翻出来看一眼。
骂完还得防。真正让它们无从下手的是「密码登录关掉」和「端口不对外」。
止损
发现后没做「清理」这种操作，直接按事故处理：
先关机，切断对方的操作通道——清理是在跟对手赛跑，没必要
关机后打快照，把现场固定下来（这台机器上的一切都可能是证据）
重启挂个临时环境，只对自己的 IP 开放，把数据捞出来
数据核对无误后，整机重装
这里有个判断很关键：不要试图「删掉后门」然后继续用。一个拿到过 root 的人，可以在任何地方留东西——内核模块、cron、systemd、甚至固件。你不可能穷举。
唯一可靠的处置是重装。
数据是怎么保住的
图床数据在对象存储的桶里，站点是纯静态文件，都落在数据盘上。把这两个目录打包：
tar czf backup.tar.gz /数据目录/minio/data /var/www
打完校验 SHA256，传到本地再核一遍。中间出过一次传输损坏，第二次才拿到一致的哈希——这一步千万不能省，一个坏包等于没备份。
教训
三条，按严重程度排：
问题
后果
默认密码（minioadmin/minioadmin）
等于没设密码，扫描器字典第一条就是它
端口对公网敞开（12 个端口）
每个端口都是一个入口，图床根本不需要公网直连
root 密码复用且偏弱
一旦进来，横向到系统层毫无阻力
还有一个隐性的：我从来没看过那台机器的日志。4466 次爆破，失败了 4466 次，没有一次触发告警，因为压根没装 fail2ban。
最后
这次没人身损失，数据也都回来了。但那种「自己的机器上跑着别人的进程」的感觉，比丢数据更让人不舒服。
后面几篇会写重装之后做了什么——SSH 换密钥、端口砍到 3 个、fail2ban、图床收回内网、评论系统搬回自己机器。都是很基础的东西，基础到出事之前我一直觉得「没必要」。
]]>
    
    https://cyk.pink/posts/7c2a91e4.html
    
    2026-10-26T14:40:00.000Z
    

      起因
一直挺得意那台轻量服务器——2 核 4G，跑着博客、图床、一个文件管理，两年没出过事。
10 月 26 号晚上翻图床的时候发现不对劲：桶里多了几个从来没上传过的文件，名字是 shell.php、.htaccess，还有一个叫 ahk_probe 的东西。第一反应是自己手滑，第二反应是——我根本没开过 PHP。
往下挖
先看的不是网站，是进程。
ps auxf | grep -v 
    
    
    2026-10-26T14:40:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      oh-my-posh 是个跨平台的终端提示符美化工具，支持 PowerShell、bash、zsh、fish、cmd。它用 JSON 配置文件定义提示符长什么样，可以显示当前目录、git 分支、执行时间、电池、天气、各种编程语言版本等。
安装
Windows 上最方便的是用 winget：
winget install JanDeDobbeleer.OhMyPosh
装完会多出一个 oh-my-posh.exe。macOS 和 Linux 可以用 Homebrew：
brew install jandedobbeleer/oh-my-posh/oh-my-posh
或者直接用官方安装脚本：
curl -s https://ohmyposh.dev/install.sh | bash
字体
oh-my-posh 的很多主题用到 Nerd Font 图标。如果看到方块或乱码，说明当前字体没有这些字形。
推荐装 MesloLGM Nerd Font 或 Cascadia Code PL。Windows Terminal 里在设置 → 外观 → 字体里选上。VS Code 终端同样要在 settings.json 里配 terminal.integrated.fontFamily。
初始化
根据你的 shell 加一句启动命令。
PowerShell（加到 $PROFILE）：
oh-my-posh init pwsh | Invoke-Expression
bash（加到 ~/.bashrc）：
eval "$(oh-my-posh init bash)"
zsh（加到 ~/.zshrc）：
eval "$(oh-my-posh init zsh)"
fish（加到 ~/.config/fish/config.fish）：
oh-my-posh init fish | source
换主题
初始化时可以直接指定主题：
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression
官方内置了很多主题，装完后主题文件一般在：
Windows：%LOCALAPPDATA%\Programs\oh-my-posh\themes\
macOS/Linux：~/.cache/oh-my-posh/themes/
想试效果可以临时运行：
oh-my-posh print primary --config "C:\path\to\theme.omp.json"
自己改配置
主题就是 JSON。一个最小结构长这样：
{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "version": 2,
  "blocks": [
    {
      "type": "prompt",
      "alignment": "left",
      "segments": [
        {
          "type": "path",
          "style": "plain",
          "foreground": "#26C6DA",
          "template": "{{ .Path }} "
        },
        {
          "type": "git",
          "style": "plain",
          "foreground": "#FFEB3B",
          "template": "({{ .HEAD }})"
        }
      ]
    }
  ]
}
segment 类型很多：path、git、executiontime、battery、node、python、go、kubectl……官方文档有完整列表。
多台机器同步
把主题文件放到 git 仓库或网盘里同步，初始化时指向固定路径。或者用环境变量 POSH_THEME 指向配置，这样换机器只需改一个变量。
$env:POSH_THEME = "C:\Users\codem\.config\oh-my-posh\mytheme.omp.json"
oh-my-posh init pwsh --config $env:POSH_THEME | Invoke-Expression
值不值得装
如果你每天大量时间在终端里，一个信息丰富、一眼能看清上下文状态的提示符确实能省不少事。oh-my-posh 配置一次，跨 shell 复用，维护成本不高。
]]>
    
    https://cyk.pink/posts/85891fe1.html
    
    2026-08-05T02:00:00.000Z
    

      oh-my-posh 是个跨平台的终端提示符美化工具，支持 PowerShell、bash、zsh、fish、cmd。它用 JSON 配置文件定义提示符长什么样，可以显示当前目录、git 分支、执行时间、电池、天气、各种编程语言版本等。

安装
Windows 上最方便的是用 winget：
winget install JanDeDobbeleer.OhMyPosh


装完会多出一个 oh-my-posh.exe。macOS 和 Linux 可以用 Homebrew：

    
    
    
    
    
    
      DOCX Pipeline 是个把 Markdown 转成中文 DOCX 的命令行工具。双后端：Pure Python 零外部依赖，Pandoc 质量更高。v1.2.0 补上了纯 Python 后端对 LaTeX 数学公式的支持，写论文、出报告时不用硬装 Pandoc。
下面先说怎么用，再简单提实现。
安装
Python 3.10 以上：
pip install git+https://github.com/redamancy231-create/docx-pipeline.git
核心依赖会一起装好：python-docx、PyYAML、click、Pillow。Pandoc 和 mermaid-cli 是可选的，后面按需安装。
一分钟上手
1. 初始化项目
docx-pipeline init --project-dir ./my-doc --template report --name "技术报告"
执行完会在 ./my-doc 下生成 project.yaml，里面包含页面、字体、路径、后端开关等所有配置。
四个内置模板：
模板
场景
默认后端
default
通用中文文档
Pure Python
academic
论文/学位论文
Pure Python
report
技术报告，带目录和 Mermaid
Pandoc
strategy
量化策略文档
Pure Python
2. 写 Markdown
模板会给你一个入口文件路径，默认在 ./md/main.md。直接写普通 Markdown 就行，公式用 $...$ 行内、$$...$$ 独立：
---
title: 示例报告
---

# 正文

考虑正弦信号的采样定理：

$$f_s \geq 2 f_{\max}$$

若采样率 $f_s = 100\,\text{Hz}$，则奈奎斯特频率为 $f_N = f_s/2 = 50\,\text{Hz}$。

## 表格

| 参数 | 值 |
|------|-----|
| 采样间隔 | 0.01 s |
| 窗长 | 21 |
3. 转换
cd ./my-doc
docx-pipeline convert --config ./project.yaml
输出路径由 project.yaml 里的 paths.docx_output 决定，默认 ./output/doc.docx。
想换输出文件：
docx-pipeline convert --config ./project.yaml --output ./out/报告.docx
只想看会不会报错，不生成文件：
docx-pipeline convert --config ./project.yaml --dry-run
常用命令
# 查看配置摘要
docx-pipeline info --config ./project.yaml

# 校验配置合法性
docx-pipeline validate --config ./project.yaml

# 强制用 Pure Python 后端
docx-pipeline convert --config ./project.yaml --method pure

# 强制用 Pandoc 后端
docx-pipeline convert --config ./project.yaml --method pandoc

# 传额外参数给 pandoc
docx-pipeline convert --config ./project.yaml --pandoc-args "--number-sections"
init 和 convert 是日常使用最多的两个命令。
配置重点
project.yaml 是全部行为的入口。几个常见调整：
改输入输出路径
paths:
  md_source: "./chapters/main.md"
  docx_output: "./output/报告.docx"
改字体
fonts:
  east_asian: "微软雅黑"
  latin: "Times New Roman"
字体必须在系统里已安装，否则 Word 会回退默认字体。
页面和缩进
page:
  size: "A4"
  orientation: "portrait"
  margins:
    top: 2.54
    bottom: 2.54
    left: 3.18
    right: 3.18

styles:
  paragraph:
    line_spacing: 1.15
    first_line_indent: 0.0   # cm，学术论文可设 0.74 左右
后端开关
pandoc:
  enabled: false          # true 启用 Pandoc
  extra_args: []
  reference_docx: ""      # Pandoc 参考文档路径
enabled: false 时走 Pure Python，LaTeX 公式由 v1.2.0 新增的 latex2mathml → MathML → OMML 桥转换。enabled: true 时走 Pandoc，公式渲染质量更好，但需要系统里有 pandoc。
后端怎么选
不想装 pandoc → Pure Python，一个 Python 环境就够了，公式也能转。
要代码语法高亮、复杂表格、章节自动编号 → Pandoc。
想精确控制中文字体、缩进、行距 → Pure Python 更直接。
Auto 模式（默认）会先看 pandoc.enabled，再看 pandoc 是否在 PATH 里，能 pandoc 就 pandoc，不能就自动降级到 Pure Python。
Mermaid 图表
report 模板默认开启 Mermaid。需要 Node.js 和 mermaid-cli：
npm install -g @mermaid-js/mermaid-cli
Markdown 里写：
```mermaid
flowchart LR
    A[输入] --> B[处理] --> C[输出]
```
转换时会自动渲染成 PNG 嵌入 DOCX。渲染失败的代码块会保留原文并加警告注释。
v1.2.0 公式实现简说
纯 Python 后端新增了一条 LaTeX → Word 原生公式的路径：
扫描 Markdown，把 $...$ 和 $$...$$ 抠出来，替换成占位符。
用 latex2mathml 把 LaTeX 转成 MathML。
用 lxml 遍历 MathML 树，生成 Word 的 m:oMath / m:oMathPara。
行内公式挂到段落里，独立公式包成居中段落。
转换失败就回退成原始 LaTeX 文本，不会让整个文档崩掉。
覆盖分数、根号、上下标、极限、n 元运算符、重音、矩阵、括号、围栏等 14 种结构，有 21 个自动化用例校验。
不过说实话，Pure Python 的 OMML 渲染在分式、根号、大型运算符等复杂式子上还是有缺陷；Pandoc 后端十五年打磨的 TeX 引擎更稳。所以能装 pandoc 的话，复杂公式建议优先 Pandoc 后端。
两个容易踩的坑
Windows 乱码
中文输出在 Windows 下可能乱码，加环境变量：
export PYTHONIOENCODING=utf-8
PowerShell：
$env:PYTHONIOENCODING = "utf-8"
目录重复
如果 Markdown 里已经手写了一个”目录”章节，pipeline 又会自动插入 Word 的 TOC 域，结果出现双目录。要么在 Markdown 里删掉手工目录，要么在 project.yaml 里设 styles.toc.enabled: false。
一句话总结
DOCX Pipeline 让 Markdown → Word 这件事可以一条命令跑完；v1.2.0 之后，公式也不需要 Pandoc 了。写报告、论文、技术文档时，它能省下大量调格式的时间。
]]>
    
    https://cyk.pink/posts/23eb6558.html
    
    2026-07-22T08:00:00.000Z
    

      DOCX Pipeline 是个把 Markdown 转成中文 DOCX 的命令行工具。双后端：Pure Python 零外部依赖，Pandoc 质量更高。v1.2.0 补上了纯 Python 后端对 LaTeX 数学公式的支持，写论文、出报告时不用硬装 Pandoc。

下面先说怎么用，再简单提实现。
安装
Python 3.10 以上：
pip install]]>
    
    
    2026-07-22T08:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      增益把深部放大后，一些横向窄的条纹、绕射尾、振铃尾也跟着被放大，在 B-scan 上冒成一片斜纹或竖条毛刺。横向平滑就是沿测线方向做均值替换，把这些窄东西糊掉，横向连续的层位则保留。
和背景去除的区别
背景去除是「减均值」：删掉横向共有的成分，留下横向局部的点目标。
横向平滑是「替换为均值」：把每道替换成左右几道的平均，抹掉横向局部的窄条纹，留下横向共有的连续层位。
两者保留的东西正好相反：
操作
去掉
保留
背景去除
减均值
横向共有（直达波、水平横条）
横向局部（钢筋双曲线）
横向平滑
替换为均值
横向局部（绕射尾、条纹）
横向共有（连续层位）
单级盒式的问题
最简单的做法是用一个矩形窗做一级滑动平均。但它的频率响应是 sinc 函数，旁瓣大——阻带里的纹波压不干净，条纹会留残影。
两级盒式更干净
做两级串联：第一级用较大窗做主要平滑，第二级用小窗磨掉第一级留下的边缘台阶。两个矩形核卷积后等效成一个梯形核，频响近似 sinc²，旁瓣比单级小得多。
实测对比（window=10）：
归一化频率
单级响应
两级响应
两级压到
0.05（通带）
0.577
0.558
97%
0.15
0.177
0.128
72%
0.25
0.091
0.030
33%
0.30
0.091
0.012
13%
通带内两者差不多，不伤层位；阻带内两级把残余压到单级的 1/3~1/8。
梯形核怎么来的
以 window=10 为例：第一级半窗 5（11 点核），第二级半窗 1（3 点核）。算中心点输出时，每个位置被几个第二级抽头「看到」：
中心位置：3 个抽头都看到，权重最大；
边缘位置：只有 1 个抽头看到，权重最小。
把「被看到的次数」画出来就是梯形：1, 2, 3, 3, …, 3, 2, 1。
窗长怎么选
只有一个参数 window：平滑跨度，单位是道数。
斜条纹还在：window 调大；
横向层位被抹糊了：window 调小，或关掉本步；
window 的物理含义 ≈ 想抹掉的横向窄目标的宽度，一般 8~20。
副作用
会抹掉横向窄的真实目标：小孤腔、细裂隙、单根细钢筋都会被糊掉。
破坏幅值定量：每个值被换成邻域均值，原始振幅信息没了。
必须放在流水线最后：它破坏幅值，所有需要真实幅值的步骤都要在它之前。
边界处理
图的两端窗会超出范围。我的做法是截断边界，只用地道内真实数据，除以实际参与平均的道数。不补零、不镜像，避免引入假象。
]]>
    
    https://cyk.pink/posts/bd00ef30.html
    
    2026-07-22T02:00:00.000Z
    

      增益把深部放大后，一些横向窄的条纹、绕射尾、振铃尾也跟着被放大，在 B-scan 上冒成一片斜纹或竖条毛刺。横向平滑就是沿测线方向做均值替换，把这些窄东西糊掉，横向连续的层位则保留。


    

    
    2026-07-22T02:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      处理一批灰度图，深部信号弱、看不清，就加了道增益（gain）把深部的幅值往上提。调完增益打开图一看，奇怪了——本来是想让深部亮起来，结果观感是浅部反而变灰了，深部也没见亮多少。第一反应是增益写错了，查了半天代码没问题。
后来才反应过来，这不是增益的 bug，是显示的色阶在捣乱。
全局百分位定色阶，会被放大后的极值撑大
显示这种动态范围很大的灰度数据，一般不会直接用最小最大值定 vmin/vmax——少数极大值（比如直达波那种）会把范围撑得太大，绝大多数数据挤在一头，图就「非黑即白」。常见的做法是用百分位，比如取第 1 和第 99 百分位作为显示的上下限，把长尾削掉，层次就出来了。
问题在于，这个百分位是整张图算的。增益一上去，深部那些本来不强、但被放大了的反射，幅值被抬得很高，整张图的 p99 跟着水涨船高（实测能从不到一万飙到二十多万）。色阶的上限一拉高，那些没被增益放大的浅部数据，在新的色阶里就全被挤向中灰了。
所以调大增益参数，看到的不是「深部变亮」，而是「浅部变灰」——因为色阶被深部的极值撑宽了，浅部在更宽的尺度里自然显得更暗。本质是灰度级被重新分配了，不是数据本身变暗。
想看增益的真实效果，得把色阶锁住
要判断增益到底有没有把深部提亮，得让前后两幅图用同一把尺子量。具体就是把「加增益前」那张图的百分位 [1,99] 记下来，加增益后显示的时候还用这同一组 vmin/vmax，不让它重新算：
vmin, vmax = np.percentile(raw, [1, 99])   # 用原始图定一次色阶

ax[0].imshow(raw,    vmin=vmin, vmax=vmax, cmap='gray')   # 原图
ax[1].imshow(gained, vmin=vmin, vmax=vmax, cmap='gray')   # 增益后，共用同一色阶
这样色阶锁死了，增益放大的深部目标是真的「冒出来」变亮，浅部因为没动还是原来的灰度，对比一目了然。配套加个「锁定色阶」的开关，勾上两图共用原始百分位，不勾就各自算各自的——平时看绝对层次用各自的，调增益判效果一定得锁。
这事给我的一个教训：调一个看起来「没生效」的处理参数，先别急着怀疑算法，想想显示环节是不是也跟着动了。增益改的是数据，百分位色阶也跟着数据重新算，两者一叠加，呈现出来的变化就不是单纯增益的效果了。判断一个处理到底有没有用，得把它放在固定的显示基准下看，不然你调的是参数，被糊弄的其实是色阶。
]]>
    
    https://cyk.pink/posts/e4b2a96c.html
    
    2026-07-15T02:30:00.000Z
    

      处理一批灰度图，深部信号弱、看不清，就加了道增益（gain）把深部的幅值往上提。调完增益打开图一看，奇怪了——本来是想让深部亮起来，结果观感是浅部反而变灰了，深部也没见亮多少。第一反应是增益写错了，查了半天代码没问题。

后来才反应过来，这不是增益的 bug，是显示的色阶在捣乱。
全局百分位定色阶，会被放大后的极值撑大
显示这种动态范围很大的灰度数据，一般不会直接用最小最大值定 vmin/vmax——少数极大值（比如直达波那种）会把范围撑得太大，绝大多数数据挤在一头，图就「非黑即白」。常见的做法是用百分位，比如取第 1 和第 99]]>
    
    
    2026-07-15T02:30:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      手电筒照得越远越暗，雷达波也一样。深部反射回波比浅部弱很多，不补一下，剖面深处就是一片黑。
深部为什么衰减
电磁波往下传，能量衰减来自两方面：
球面扩散：能量摊开，随距离平方变弱（∝ 1/r²）；
介电吸收：介质吸能，随距离指数衰减（∝ e^(−αz)）。
深部反射体回波可能比浅部弱 40~60dB。
时间增益：按时间乘一条固定曲线
造一条随时间单调增长的曲线 $G(t)$，每道信号逐样点乘上去。浅处乘得小，深处乘得大。
三种常见形状：
$$G(t)=\begin{cases}1+p,t & \text{linear}\ e^{,p,t} & \text{exp}\ t^{,p}\text{ 归一化} & \text{power}\end{cases}$$
指数型最贴合指数吸收的物理。设 p=0.051，dt=0.054ns，512 个样点：
位置
时间
增益
相当于
浅
0 ns
1.00
+0 dB
中
10 ns
1.66
+4.4 dB
深
27.6 ns
4.09
+12.2 dB
最深处放大约 4 倍，原本看不见的弱反射被拉到可看的亮度。
不过别搞错：时间增益不是真正的反衰减，真实吸收系数未知。它只是显示补偿，不是物理还原。
AGC：自动音量
AGC 像耳机自动音量：强处压小、弱处放大，让每个深度看起来差不多强。
对每个样点，取前后小窗口算局部 RMS 能量，然后该样点除以这个 RMS：
$$\text{rms}[n]=\sqrt{\frac{1}{W}\sum_{k=-W/2}^{W/2}x[n+k]^2+\varepsilon},\qquad \text{out}[n]=\frac{x[n]}{\text{rms}[n]}$$
强段除以大数变小，弱段除以小数变大，每小段能量都被归一到约 1。
两者差别
时间增益
AGC
曲线
固定预设
看数据自适应算
依据
时间位置
邻域实际能量
效果
温和补深部
强行抹平强弱差
副作用
改变幅值
彻底破坏幅值
gain 后会重新引入直流
即使 gain 前每道已经是零均值，gain 之后均值又可能不等于 0。增益曲线恒正递增，深部样点被放大更多，会把整道均值往深部拽偏。
举个例子，dewow 后零均值的道：
x        = [ 1, -1,  1, -1]     均值 = 0
G        = [ 1,  2,  3,  4]     (浅→深递增)
x·G      = [ 1, -2,  3, -4]     均值 = -0.5
减均值后  = [1.5,-1.5,3.5,-4.5]  均值 = 0
所以有些流程在 gain 后再减一次每道均值，称为 post_gain_dc。它跟 dewow 不是一回事：dewow 是去低频漂移，post_gain_dc 是清 gain 新引入的直流。
注意事项
增益/AGC 会放大噪声，调太大深部就全是雪花。
改变幅值关系，不能定量。「反射越强 = 病害越重」必须回原始数据。
AGC 比固定增益更激进，仅用于显示和目标识别，绝不能用于定量。
AGC 窗长一般取目标回波持续长度的 2~3 倍；固定增益的 p 调到深部看得见、但噪声还没明显冒出来就行。
]]>
    
    https://cyk.pink/posts/5c056d5b.html
    
    2026-07-15T02:00:00.000Z
    

      手电筒照得越远越暗，雷达波也一样。深部反射回波比浅部弱很多，不补一下，剖面深处就是一片黑。

深部为什么衰减
电磁波往下传，能量衰减来自两方面：

球面扩散：能量摊开，随距离平方变弱（∝ 1/r²）；
介电吸收：介质吸能，随距离指数衰减（∝ e^(−αz)）。

深部反射体回波可能比浅部弱 40~60dB。
时间增益：按时间乘一条固定曲线
造一条随时间单调增长的曲线]]>
    
    
    2026-07-15T02:00:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      把一批 16 位采样的数据读进来做了点预处理（去直流、去背景这种减法操作），再写回原来的二进制文件给别的专业软件打开。读进来处理的时候一切正常，写回去打开一看，有的文件好好的，有的直接满屏噪点、糊成一团。同样的代码、同样的处理，结果天差地别，卡了好一阵。
根子是 16 位整数到底按有符号还是无符号解读，不是统一的，取决于文件格式。
同样 16 位，有的围绕 0 有的围绕 32768
这批数据两种格式：一种是无符号 16 位（unsigned），数据的载波零点在 32768，数值在 065535 之间抖；另一种是有符号 16 位（signed），围绕 0 抖，范围是 −3276832767。同样是两个字节 00 80，按无符号读是 32768，按有符号读（小端）是 −32768，完全是两码事。
读的时候按各自格式来，没问题。问题出在写回。
减法预处理之后有了负值
去直流、去背景这类操作本质是减法：估一个背景再从原数据里减掉。减完之后，数据就从「围绕 32768」或者「围绕 0」变成了「围绕 0」，而且必然出现负值（原来低于背景的地方）。
写回有符号格式（围绕 0）的那种文件，很直接——数据本来就围绕 0，减完还是围绕 0，按有符号 clamp 到 [−32768, 32767] 写进去就行，啥额外操作都不用加。
但写回无符号格式（围绕 32768）的那种文件就出事了：减法之后围绕 0、带负值，直接当无符号写回去，那些负值会被解释成 65536 附近的超大数，落在一个本该是中灰的位置上全是亮点，整张图就满屏噪点了。
写回无符号得先平移回它的基准
所以写回无符号格式之前，得先把数据从「围绕 0」平移回「围绕 32768」——加一个全图统一的直流基准（大概就是整图的均值，约等于 32768），把负值整体抬进 0~65535 的范围，再 clamp：
if target_unsigned:
    dc_base = int(round(data.mean()))     # 全图统一的基准，约 32768
    out = data + dc_base                   # 平移回无符号范围
    out = np.clip(out, 0, 65535).astype('<u2')
else:
    out = np.clip(data, -32768, 32767).astype('<i2')   # 有符号直接 clamp，不加基准
有个反着的坑得强调一下：写回有符号格式绝对不能也傻乎乎加个 +32768 的基准。因为数据本来围绕 0，加完 32768 之后落到 32768 附近，再被 (short) 强转，超过 32767 的部分直接溢回 −32768，数据当场写坏。也就是说 clamp 方式必须按目标格式二选一，不能图省事统一一套。
还有一个细节：那个直流基准必须是全图统一的一个值，不能用每一道各自的均值。用各道均值的话，等于把每道都单独拉回自己的 32768，结果是保留了各道之间的直流差——这恰恰是去直流、去背景想抹掉的东西，效果会差很远。这一条是走过弯路之后才纠正过来的：一开始图精确用了各道均值，结果处理完的图还不如不平移干净，换成全图统一直流基准才对。
说到底，这事的核心就一句：16 位数据的有符号、无符号不是读的时候定死就完了，写回的时候还得按目标格式再判一次。同样是「减完带负值」的中间结果，写回有符号和无符号要走的 clamp 路径完全不同，搞混了就是满屏噪点和数据写坏的区别。
]]>
    
    https://cyk.pink/posts/d6c7a14b.html
    
    2026-07-14T05:25:00.000Z
    

      把一批 16 位采样的数据读进来做了点预处理（去直流、去背景这种减法操作），再写回原来的二进制文件给别的专业软件打开。读进来处理的时候一切正常，写回去打开一看，有的文件好好的，有的直接满屏噪点、糊成一团。同样的代码、同样的处理，结果天差地别，卡了好一阵。

根子是 16 位整数到底按有符号还是无符号解读，不是统一的，取决于文件格式。
同样 16 位，有的围绕 0 有的围绕 32768
这批数据两种格式：一种是无符号 16 位（unsigned），数据的载波零点在 32768，数值在 065535 之间抖；另一种是有符号 16 位（signed），围绕 0 抖，范围是 −3276832767。同样是两个字节 00 80，按无符号读是]]>
    
    
    2026-07-14T05:25:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      手上有一批设备采集下来的二进制数据，没文档，只有几组不同后缀的文件，要把它们读出来画图。全程靠 hex 编辑器一点点猜，记一下逆向这种私有二进制格式的大概路数，顺便记一个踩得很疼的 off-by-one。
先把头和样点数摸清楚
这种采集文件，基本结构都是「一个文件头 + 后面一大片采样数据」。第一步是估文件头多大。把文件丢进 hex 编辑器，前面一段往往是固定模式、跟后面的「数据区」长得不一样，头一般是个整数（512、1024、2048 这种）。这批文件摸下来头是 1024 字节。
样点数通常藏在文件头的某个偏移里。怎么找——算一道简单除法：(文件总大小 - 头) / 每道字节数 = 道数，而 每道字节数 = 样点数 × 每个样点的字节。如果数据是 16 位（2 字节）存的，那去文件头里找一个值，使得「头之后的字节数 / 2 / 这个值」是个整数、而且这个值本身是合理的样点数（比如 512）。这批文件样点数在头偏移 4 的位置，值是 512。
到这里，最朴素的读法就有了：跳过 1024 头，后面按 int16 一道一道读：
nsamp = 512           # 头里偏移4读出来的样点数
header = 1024         # 头大小
raw = np.frombuffer(data[header:], dtype='<i2')   # 小端 int16
ntrace = raw.size // nsamp
traces = raw[:ntrace * nsamp].reshape(ntrace, nsamp)
用 magic 字节区分格式
事情没这么简单，因为这批数据有四种后缀、对应四种格式，得知道手里这份是哪种。靠后缀判断不可靠（后缀能随便改），靠谱的是文件头里的「魔数」——每个格式在固定位置有一段独特的字节，相当于这个格式的身份证。
实测下来这批文件：一种开头是 00 07，一种是 56 04 00 00 04 04 00 00，另两种是 01 00 或 00 00。读的时候先嗅探（sniff）一下这几个字节，命中哪种就走哪种的解析器，后缀只当兜底：
def read_auto(path):
    head = open(path, 'rb').read(8)
    if head[:2] == b'\x00\x07':          return read_kind_a(path)
    if head[:4] == b'\x56\x04\x00\x00':  return read_kind_b(path)
    # 剩下的退回看后缀
    ...
有意思的是，其中三种格式摸到最后发现是同一个套路——都是 [1024 头][int16 数据]，只是 magic 不一样，连样点数偏移都一样（纯属不同厂家巧合撞了布局）。所以这三个的解析逻辑抽到了一个公共函数，各自只是薄薄包一层填自己的 magic。
一个 off-by-one，数据道数多算一条
真正折腾人的是第四种。一开始按老套路把它当「[1024 头][int16]」来读，画出来的图第一道总是一根奇怪的直线、后面整体对不齐，怎么调参数都不对。
后来把它的字节流摊开一格一格看，才发现它根本不是「全局头 + 数据」那种结构，而是定长记录流：整个文件就是一条条固定 1028 字节的记录首尾拼接，没有独立的全局头。而且记录还分类型：
第 0 条是「头记录」，前 4 字节是类型码 1110，后面基本是 0；
后面才是数据道记录，每条开头是类型码 82，再跟 512 个 int16 样点。
之前的读法把第 0 条头记录也当成了数据道，所以道数多算了一条、第一道里混进了那条头记录的残值，图自然对不齐。改完之后，先检测开头是不是 1110、是的话跳过这条头记录，真实道数从第 1 条开始数，图一下就正了。
def read_record_stream(data):
    rec = 1028
    nrec = len(data) // rec
    first = np.frombuffer(data[:4], dtype='<i4')[0]
    start = 1 if first == 1110 else 0      # 头记录(type=1110)不算数据道
    traces = []
    for i in range(start, nrec):
        seg = data[i*rec + 4 : i*rec + 4 + 512*2]   # 跳过 type 码读 512 样点
        traces.append(np.frombuffer(seg, dtype='<i2'))
    return np.array(traces)
逆向这种没文档的二进制格式，路数其实挺固定：先估头大小、再从文件大小反推样点数偏移、用 magic 区分同源的几种格式、剩下就是格格里看字节把记录结构猜出来。最后那个 off-by-one 也提醒一件事——别想当然觉得同一批数据都是一种结构，哪怕是同一个采集软件出的，不同后缀可能用的是完全不同的文件模型，按老套路硬套就会多算一条少算一条。
]]>
    
    https://cyk.pink/posts/8b2c5e91.html
    
    2026-07-13T01:40:00.000Z
    

      手上有一批设备采集下来的二进制数据，没文档，只有几组不同后缀的文件，要把它们读出来画图。全程靠 hex 编辑器一点点猜，记一下逆向这种私有二进制格式的大概路数，顺便记一个踩得很疼的 off-by-one。

先把头和样点数摸清楚
这种采集文件，基本结构都是「一个文件头 + 后面一大片采样数据」。第一步是估文件头多大。把文件丢进 hex 编辑器，前面一段往往是固定模式、跟后面的「数据区」长得不一样，头一般是个整数（512、1024、2048 这种）。这批文件摸下来头是 1024 字节。
样点数通常藏在文件头的某个偏移里。怎么找——算一道简单除法：(文件总大小 - 头) / 每道字节数 = 道数，而 每道字节数 = 样点数 × 每个样点的字节。如果数据是 16 位（2 字节）存的，那去文件头里找一个值，使得「头之后的字节数]]>
    
    
    2026-07-13T01:40:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      雷达数据做完前面的清洗，最后一步往往是加增益（gain）。深部反射看不见、一团黑，加完增益深部就亮起来了。但增益到底在补什么、补多少有讲究，不是无脑把深部拉亮就行。另外有篇单独讲做完增益之后显示色阶的坑，这篇只讲增益算法本身。
为什么要补：深部比浅部弱太多
电磁波往地下走，越深衰减越厉害，所以深处的反射回到天线时已经弱了一大截。一道信号画出来，浅部反射很强、深部几乎贴着噪声底，深部想看的目标（比如衬砌后面的脱空）就淹没在里面。增益的作用就是把这个随深度掉下去的幅度，人为往上提一提，让深浅在图上都能看见。
衰减有两种，数学形式不一样
深部变弱这件事，根上有两个来源，得分开看。一个是几何扩散——波往外是球面扩散的，能量摊到越来越大的球面上，幅度按幂律（大约 1/距离）往下掉。另一个是介电吸收——介质本身把电磁能吃掉一部分，这个是按指数 e^(−α·深度) 掉的。
关键在于这俩数学形式不同：一个是幂律、一个是指数。所以想补偿，也得用对应的形式去补，硬拿一个套另一个补不齐。
两种增益对应两种衰减
增益常见的两种类型正好对应上：power 型按幂律补，对应几何扩散；exp 型按指数补，对应介电吸收。要补哪种衰减就选哪种类型。实际数据里两种衰减同时存在，单用 exp 其实只补了吸收那部分，几何扩散那块没单独补——这正是后面会看到的「补不满」的根因。
exp 的参数 p 不是拍脑袋
exp 增益的形式是逐点乘一条指数曲线，关键参数是 p。这里有个容易踩的坑：p 的单位是 1/ns，物理上等于 α·v——α 是介质的吸收系数（每米吸收多少），v 是波速（每纳秒走多少米）。所以 p 不是随便给的数，是能从数据反推的：算一下能量随时间的衰减斜率（对数能量随时间的斜率），那基本就是 α·v，也就是该用的 p。实测下来一批数据这个斜率大概在 -0.045/ns 附近，用 0.05/ns 左右就接近数据本身反推出来的值。
故意不补满
这里有个反直觉的点：实测深部相对浅部衰减了大约 18.5dB，但用 exp(0.05) 只补回来约 12dB，还留着约 6dB 没补。这不算错，是故意的。补得太狠，深浅都被拉平，深部强反射和浅部一样亮，反而看不出深浅层次了。判厚度、判脱空这些是要靠相对强弱判断的，全拉平了反倒没法判。所以温和地补、留一点层次，是刻意的。真要完全补平，p 得往 0.077 那边走。
换句话说，增益是个显示补偿，不是物理反演。它把每道逐点乘同一条 G(t) 曲线（所有道乘同一条），目的是让人眼看得见深部，但不会把衰减掉的能量真的还原回来。增益后的幅值不能拿来当真实幅值定量算。
保幅就别用 AGC
还有个 AGC（自动增益控制），它不分深浅物理机制，直接把局部能量拉平归一——原来局部能量跨深度抖得很厉害（标准差好几千），AGC 一压，各处都归到差不多 1，标准差能压到零点零几。看图特别爽，深浅都清楚。但代价是幅值信息全没了：哪里本来强、哪里本来弱，AGC 之后全都拉平，相对强弱看不出来了。
所以选 exp 还是 AGC，看目的。要保幅、要做定量判读（靠幅值判厚度、判脱空含水），就用 exp，别用 AGC。AGC 只适合纯粹看个图、不在乎幅值大小的场景。
切类型要重定参数
最后说个具体的坑：exp 的 p 单位是 1/ns，power 的 p 是个无量纲的幂指数，这俩「p」名字一样但含义完全不同。从 exp 切到 power（或反过来），参数不能直接照搬，得按新类型的含义重新定，不然补出来的曲线完全不是想要的那条。
增益这一步看着简单（就是逐点乘一条曲线），真正要拿捏的是补什么、补多少。补的是随深度掉的幅度，形式得匹配衰减机制（幂律对几何、指数对吸收），力度上故意留一点层次别拉平，保幅用 exp、纯看图才用 AGC。把它当显示补偿、不当物理反演，就不会指望它把深部能量真的还原回来。
]]>
    
    https://cyk.pink/posts/9c4e8a2f.html
    
    2026-07-12T01:30:00.000Z
    

      雷达数据做完前面的清洗，最后一步往往是加增益（gain）。深部反射看不见、一团黑，加完增益深部就亮起来了。但增益到底在补什么、补多少有讲究，不是无脑把深部拉亮就行。另外有篇单独讲做完增益之后显示色阶的坑，这篇只讲增益算法本身。

为什么要补：深部比浅部弱太多
电磁波往地下走，越深衰减越厉害，所以深处的反射回到天线时已经弱了一大截。一道信号画出来，浅部反射很强、深部几乎贴着噪声底，深部想看的目标（比如衬砌后面的脱空）就淹没在里面。增益的作用就是把这个随深度掉下去的幅度，人为往上提一提，让深浅在图上都能看见。

    

    
    2026-07-12T01:30:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      给桌面软件接了一套登录许可证，启动的时候要过一串校验，任一条不过就直接锁应用。licence 防破解的一些具体坑（时间回拨、指纹漂移）之前写过，这里不重复，主要想理一下：一张许可证启动时到底该查哪些项，以及其中几个不那么直观的、容易漏掉的检查。
整体是个串行链条，前面是许可证本身合不合法，后面是运行环境对不对，最后才是用户名密码。哪一环断了都锁，不是「前面过了后面就随便」。
许可证本体这几项
先是把许可证解析出来，格式不对、签名解析失败，直接锁。然后是有效期，过期了锁——但有效期的判断会被改系统时间绕掉，这块得配合本地单调时间记录来防回拨，之前那篇说过的思路，这里不展开。接着是硬件指纹比对，确认现在这台机器就是许可证绑的那台，防一份 licence 拷来拷去到处用。
这几项是基础，大多数做 licence 的人都会想到。
版本号得跟软件版本对上
这条我觉得容易被忽略。许可证里带一个版本号字段，校验的时候不能只看它「有没有」，得看它是不是等于当前软件的版本。
为什么重要——因为软件会迭代。一份在 v2 时代签发的 licence，里面版本号写的是 2，用户拿着它去跑 v3，如果不校验版本，v3 照样认这份老 licence。这就留下一个口子：买了旧版的人拿着旧 licence 一直白嫖新版本。绑死版本号之后，大版本升级要么重新签发、要么 licence 里显式声明向前兼容哪些版本，主动权在签发方手里。
注册目录得是当初注册的那个
这条更隐蔽。注册成功的时候，把「当时所在的安装目录」记进许可证或者本地凭证里。下次启动，拿当前程序的运行目录（user.dir）跟记下来的那个比一下，不一致就锁。
防的是这种操作：用户在一台机器上注册成功了，然后把整个安装目录连着注册凭证一起打包，拷到另一台机器上跑。光靠硬件指纹的话，如果两台机器硬件凑巧接近、或者指纹本身不够强，可能蒙混过去。但目录是物理路径，拷到别的机器上基本不可能还在同一个绝对路径下，这条等于多加了一层「这确实是当初那台机器、那个位置」的绑定。
配置校核防的是改配置
还有个配置校核（proofread）：启动时把关键的本地配置重新算一遍校验和，跟之前存的比对。防的是破解者不去动 licence 本体（那个有签名，动不了），转而去改本地的配置文件——比如把「已激活」标志、剩余时长这些写死成有利值。配置一旦被改，校验和对不上，锁。
这条的逻辑是：licence 本体有签名护着改不动，那攻击者最可能下手的就是没有签名保护的本地配置，得给这部分也上个完整性校验。
最后才是用户名密码
所有上面的环境校验都过了，才走到用户名密码这一步。它放在最后是有讲究的：用户名密码防的是「会操作电脑但不会逆向」的人，真正能破前面那些链路的人，根本不需要猜密码。所以把它放最前面没意义，先确认环境和许可证没问题，最后再用密码挡一道普通使用者层面的越权。
这一串串起来，思路其实就是「licence 本体靠签名、运行环境靠多维度绑定」。签名保证许可证没被改，版本号、目录、配置校核把「拿合法 licence 换个环境用」这条路一层层堵上，最后用密码挡住普通越权。哪条单独拎出来都不绝对，但叠成一个链条之后，想绕过去得同时把好几处都对上，门槛就上去了。
]]>
    
    https://cyk.pink/posts/3f7d9c2b.html
    
    2026-07-11T07:55:00.000Z
    

      给桌面软件接了一套登录许可证，启动的时候要过一串校验，任一条不过就直接锁应用。licence 防破解的一些具体坑（时间回拨、指纹漂移）之前写过，这里不重复，主要想理一下：一张许可证启动时到底该查哪些项，以及其中几个不那么直观的、容易漏掉的检查。

整体是个串行链条，前面是许可证本身合不合法，后面是运行环境对不对，最后才是用户名密码。哪一环断了都锁，不是「前面过了后面就随便」。
许可证本体这几项
先是把许可证解析出来，格式不对、签名解析失败，直接锁。然后是有效期，过期了锁——但有效期的判断会被改系统时间绕掉，这块得配合本地单调时间记录来防回拨，之前那篇说过的思路，这里不展开。接着是硬件指纹比对，确认现在这台机器就是许可证绑的那台，防一份 licence 拷来拷去到处用。
这几项是基础，大多数做 licence 的人都会想到。

    
    
    2026-07-11T07:55:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
    
      做了个注册机给桌面软件签发许可证，注册机本身有个管理员解锁密码——不是最终用户的密码，是防止谁都能进来乱签 license 的那道门。一开始图省事，密码明文写在 gradle.properties 里，程序运行的时候读出来比对。能用是能用，但越想越不对劲。
问题在于，这个密码随包一起发出去了。gradle.properties 里的值，打包完之后会以某种形式落到产物里，最差就是直接生成一个 register.properties 跟着 exe 走。破解者拿到发版包，翻一翻配置文件，明文密码就在那儿躺着，这道门等于没上锁。
后来改成这样：密码在打包阶段就转成 MD5，然后通过 exe4j 的 VM 参数固化进 exe，运行时直接从系统属性里读 MD5 来比对，全程不落外部配置文件。
打包脚本里大致是：
// 打包时把明文密码算成 MD5，塞进 exe4j 的 VM 参数
def pwdMd5 = md5(project.property('registerPassword'))
def vmArgs = "-Dregister.password.md5=${pwdMd5}"
// 这段 vmArgs 写进 exe4j 配置，随 exe 一起固化
运行时校验这边，按优先级找这个 MD5：
private String resolveExpectedPasswordMd5() {
    // 1. 打包时通过 -Dregister.password.md5 注入的（生产）
    String md5 = System.getProperty("register.password.md5");
    if (StringUtils.isNotEmpty(md5)) {
        return md5;
    }
    // 2. 开发态 IDEA 直接跑，读 properties 里的明文现算（仅本机）
    String pwd = loadDevProperties().getProperty("registerPassword");
    if (StringUtils.isNotEmpty(pwd)) {
        return md5(pwd);
    }
    // 3. 兜底
    return md5(FALLBACK_PASSWORD);
}
用户输入密码，同样 md5 一遍，跟期望值比，对得上才放行。全程只存和比 MD5，明文密码不进运行态、不落盘。
这么改之后几个好处。一是发版包里翻不到明文密码了，最起码「翻配置文件」这条路堵死了，想拿原值得反 exe。二是 VM 参数 -D 是打进 exe4j 配置、随 exe 固化的，不是旁边带个文件，没那么容易被一眼发现和替换。三是开发态不受影响——IDEA 里直接跑 main 的时候没有那个 VM 参数，就走第二条读 properties 现算，本机调试照样方便。
当然这不是什么高强度的防护，MD5 本身早不该直接用来存密码（正经得加盐、用慢哈希），注册机这个场景门槛要求没那么高，这么搞够用。真要紧的是别把明文密码跟包一起发出去——那不叫加密，那叫附赠钥匙。
]]>
    
    https://cyk.pink/posts/c4e2b81a.html
    
    2026-07-10T03:08:00.000Z
    

      做了个注册机给桌面软件签发许可证，注册机本身有个管理员解锁密码——不是最终用户的密码，是防止谁都能进来乱签 license 的那道门。一开始图省事，密码明文写在 gradle.properties 里，程序运行的时候读出来比对。能用是能用，但越想越不对劲。

问题在于，这个密码随包一起发出去了。gradle.properties 里的值，打包完之后会以某种形式落到产物里，最差就是直接生成一个 register.properties 跟着 exe 走。破解者拿到发版包，翻一翻配置文件，明文密码就在那儿躺着，这道门等于没上锁。
后来改成这样：密码在打包阶段就转成 MD5，然后通过 exe4j 的 VM 参数固化进 exe，运行时直接从系统属性里读 MD5 来比对，全程不落外部配置文件。
打包脚本里大致是：

    
    
    2026-07-10T03:08:00.000Z
  
  
    
      CYK
    
    
    
    
    
    
      用 exe4j 把一个 JavaFX 桌面程序打成 exe，自带 JRE 一起发出去，结果双击 exe 直接弹「找不到 jvm」之类的错。机器上明明装了 Java，自带的 JRE 目录也都在，就是起不来。
折腾一圈发现是 exe4j 找 JRE 的路径没配对。
exe4j 打出来的 exe 本质是个启动器，它自己不包含 JVM，运行的时候要先在机器上找一个可用的 JRE 再拉起真正的程序。它找 JRE 是按一个「搜索顺序」来的，默认会先去找系统注册的 Java、JAVA_HOME 之类，找不到才往下走。问题就出在这：开发机上系统 Java 是高版本的，能蒙混过去；到了用户那台干净机器上，啥系统 Java 都没有，它又没被告诉「去我自带的那个 ./jre 里找」，自然就报找不到。
修法是在 exe4j 的配置里显式给一个搜索路径，优先指向打包进去的那个 JRE 目录。exe4j 的配置是份 xml，对应的是 <searchSequence> 这一段：
<searchSequence>
  <directory location="./jre" />
</searchSequence>
就是把「相对于 exe 所在目录的 ./jre」放到搜索序列的最前面。打包的时候把精简过的 JRE（我用 jlink 裁了一份只含要用的模块的）整个放到发版目录的 jre/ 下，exe 起来就先从这儿找，稳稳命中自带的那份，跟用户机器上装没装 Java 彻底脱钩。
有个坑顺带说一下：这个 JRE 目录名得和配置里写的对得上，打包脚本挪文件的时候别把 jre 改名或者放到别的层级，否则 ./jre 这个相对路径就指空了，又是同样找不到的报错。我用 Gradle task 自动生成这份 exe4j 配置 + 拷 JRE，两步用同一个目录变量串起来，省得手抖对不上。
其实这类「在我这好好的、到你那不行」的问题，根子基本都是把开发机上的环境当成了默认环境。启动器找 JRE 这种事，别指望它自己去猜，显式把自带 JRE 的路径塞到搜索序列最前面，一份自包含的 exe 才算真的能到处跑。
]]>
    
    https://cyk.pink/posts/9f3a7c2e.html
    
    2026-07-09T08:20:00.000Z
    

      用 exe4j 把一个 JavaFX 桌面程序打成 exe，自带 JRE 一起发出去，结果双击 exe 直接弹「找不到 jvm」之类的错。机器上明明装了 Java，自带的 JRE 目录也都在，就是起不来。

折腾一圈发现是 exe4j 找 JRE 的路径没配对。
exe4j 打出来的 exe 本质是个启动器，它自己不包含 JVM，运行的时候要先在机器上找一个可用的 JRE 再拉起真正的程序。它找 JRE 是按一个「搜索顺序」来的，默认会先去找系统注册的 Java、JAVA_HOME 之类，找不到才往下走。问题就出在这：开发机上系统 Java 是高版本的，能蒙混过去；到了用户那台干净机器上，啥系统 Java 都没有，它又没被告诉「去我自带的那个 ./jre 里找」，自然就报找不到。
修法是在 exe4j 的配置里显式给一个搜索路径，优先指向打包进去的那个 JRE 目录。exe4j 的配置是份 xml，对应的是 <searchSequence>]]>
    
    
    2026-07-09T08:20:00.000Z