评论区加载不出来？把 Twikoo 从 Vercel 搬回自己服务器
现象博客的评论区一直在转圈，一直以为是「没人评论所以空的」。
直到有一天为了查别的问题去调评论接口，发现请求根本没回来：
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 是好的。
这也解释了为 ...
静态博客的传输层优化：HTTP/2、gzip 和缓存头
先量化，再优化重装之后顺手给站点做了一次体检，四个数字最扎眼：
指标
数值
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 才算真的开了。
gz ...
重装只是开始：把公网服务器从裸奔状态拉回来
重装之后的第一件事不是装软件系统重装完，ssh root@ip 一通，密码进去——这一步就已经错了。
上一台机器出事，本质就是「密码可以被人猜」。所以这次第一件事是：把密码登录这条路彻底关掉，改成密钥。
SSH 换密钥本地生成一对 ed25519（比 RSA 短、比 RSA 快、强度还更高）：
ssh-keygen -t ed25519 -f ~/.ssh/cyk_server -N ""
把公钥追加到服务器的 ~/.ssh/authorized_keys，权限必须是这套：
chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keys
然后写一份加固配置，放在 sshd_config.d/ 下（注意文件名要排在云厂商的默认配置前面，因为 sshd 是「先读到的生效」）：
PasswordAuthentication noKbdInteractiveAuthentication noPermitRootLogin prohibit-passwordMaxAuthTries 3
prohibit-password 的意思不是「允 ...
服务器被拿去当肉鸡：一次入侵的完整复盘
起因一直挺得意那台轻量服务器——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 ...
oh-my-posh：一个好看的终端提示符怎么装
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 终端同样要在 se ...
DOCX Pipeline v1.2.0：Markdown 转 Word，顺便把 LaTeX 公式也塞进去
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，里面包含页面、字体、路径、后端开关等所有配置。
四个内置模板：
模板
场景
默认后端
d ...
横向平滑：抹掉 GPR 剖面上的窄条纹
增益把深部放大后，一些横向窄的条纹、绕射尾、振铃尾也跟着被放大，在 B-scan 上冒成一片斜纹或竖条毛刺。横向平滑就是沿测线方向做均值替换，把这些窄东西糊掉，横向连续的层位则保留。
和背景去除的区别背景去除是「减均值」：删掉横向共有的成分，留下横向局部的点目标。
横向平滑是「替换为均值」：把每道替换成左右几道的平均，抹掉横向局部的窄条纹，留下横向共有的连续层位。
两者保留的东西正好相反：
操作
去掉
保留
背景去除
减均值
横向共有（直达波、水平横条）
横向局部（钢筋双曲线）
横向平滑
替换为均值
横向局部（绕射尾、条纹）
横向共有（连续层位）
单级盒式的问题最简单的做法是用一个矩形窗做一级滑动平均。但它的频率响应是 sinc 函数，旁瓣大——阻带里的纹波压不干净，条纹会留残影。
两级盒式更干净做两级串联：第一级用较大窗做主要平滑，第二级用小窗磨掉第一级留下的边缘台阶。两个矩形核卷积后等效成一个梯形核，频响近似 sinc²，旁瓣比单级小得多。
实测对比（window=10）：
归一化频率
单级响应
两级响应
两级压到
0.05（通带）
0. ...
给图像做完增益别再用整张图的百分位定色阶
处理一批灰度图，深部信号弱、看不清，就加了道增益（gain）把深部的幅值往上提。调完增益打开图一看，奇怪了——本来是想让深部亮起来，结果观感是浅部反而变灰了，深部也没见亮多少。第一反应是增益写错了，查了半天代码没问题。
后来才反应过来，这不是增益的 bug，是显示的色阶在捣乱。
全局百分位定色阶，会被放大后的极值撑大显示这种动态范围很大的灰度数据，一般不会直接用最小最大值定 vmin/vmax——少数极大值（比如直达波那种）会把范围撑得太大，绝大多数数据挤在一头，图就「非黑即白」。常见的做法是用百分位，比如取第 1 和第 99 百分位作为显示的上下限，把长尾削掉，层次就出来了。
问题在于，这个百分位是整张图算的。增益一上去，深部那些本来不强、但被放大了的反射，幅值被抬得很高，整张图的 p99 跟着水涨船高（实测能从不到一万飙到二十多万）。色阶的上限一拉高，那些没被增益放大的浅部数据，在新的色阶里就全被挤向中灰了。
所以调大增益参数，看到的不是「深部变亮」，而是「浅部变灰」——因为色阶被深部的极值撑宽了，浅部在更宽的尺度里自然显得更暗。本质是灰度级被重新分配了，不是数据本身变暗 ...
GPR 时间增益与 AGC：把深部提亮的两条路
手电筒照得越远越暗，雷达波也一样。深部反射回波比浅部弱很多，不补一下，剖面深处就是一片黑。
深部为什么衰减电磁波往下传，能量衰减来自两方面：
球面扩散：能量摊开，随距离平方变弱（∝ 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
最深处 ...
16 位整数写回文件有符号和无符号要分开 clamp
把一批 16 位采样的数据读进来做了点预处理（去直流、去背景这种减法操作），再写回原来的二进制文件给别的专业软件打开。读进来处理的时候一切正常，写回去打开一看，有的文件好好的，有的直接满屏噪点、糊成一团。同样的代码、同样的处理，结果天差地别，卡了好一阵。
根子是 16 位整数到底按有符号还是无符号解读，不是统一的，取决于文件格式。
同样 16 位，有的围绕 0 有的围绕 32768这批数据两种格式：一种是无符号 16 位（unsigned），数据的载波零点在 32768，数值在 065535 之间抖；另一种是有符号 16 位（signed），围绕 0 抖，范围是 −3276832767。同样是两个字节 00 80，按无符号读是 32768，按有符号读（小端）是 −32768，完全是两码事。
读的时候按各自格式来，没问题。问题出在写回。
减法预处理之后有了负值去直流、去背景这类操作本质是减法：估一个背景再从原数据里减掉。减完之后，数据就从「围绕 32768」或者「围绕 0」变成了「围绕 0」，而且必然出现负值（原来低于背景的地方）。
写回有符号格式（围绕 0）的那种文件，很直接——数据本 ...