上学期间，每学期都会产生很多docx、pptx、pdf等，或许是结课论文，或许是课堂汇报ppt，或许是要交的材料文件，总爱做一份备份。
既是记录生活，也是存下过去。

由于我有两台电脑，而且手机也是也需要查看，所以云端必不可少。
往往还需要发给别人看，需要发送链接。

国内那些云盘有多难用，我就没必要赘述了。

过去一直用的OneDrive。但只有5GB免费空间，同步又需要走微软服务器，需要常驻后台进程，还会有延迟和强占带宽。

如果两台电脑同时开着同一个docx更麻烦。同步回来多出一个名字带(2)的副本，哪个是新的得自己判断。

最好的记录方式当然是git实在是小题大做。

但是既然可取，何不试试？
私有仓库，564个文件，711.1MiB，12个提交。

拦截大文件

由于GitHub的限制，单文件不可以超过100MB，所以做了一个钩子来避免上传超过100MB的文件。

1

/your/path/cloud-storage/.git/hooks/pre-commit

1
2
3
4
5
6
7
8

MAX_SIZE=$((100 * 1024 * 1024))   # 100MB
git diff --cached --name-only --diff-filter=ACM | while read f; do
  size=$(stat -f%z "$f")
  if [ "$size" -gt "$MAX_SIZE" ]; then
    git restore --staged "$f"     # 移出暂存区，不阻止提交
  fi
done
exit 0

文件组成

那么高清好看的壁纸居然不可以作为动态壁纸播放！太糟糕了！

市面上有很多动态壁纸的软件，但是他们大多软件功能复杂，操作繁琐，价格高昂，语言不便，并且自带下载视频，而不是播放系统壁纸视频。

项目已在GitHub开源，地址：Lumina

9个Swift文件，2995行，Xcode Command Line Tools编译，无需引第三方库。

同步发布软件包，可以直接下载使用。

第一次运行会自动寻找系统自带的Aerial素材，在~/Library/Application Support/com.apple.wallpaper/aerials/videos/下面，缓存的壁纸文件mov路径，也可以自备视频。

软件制作困难

遮挡

视频壁纸并未直接替代原壁纸图片，而是选择新建图层覆盖。

macOS的桌面有多层窗口。用CGWindowListCopyWindowInfodump出来如下：

动态壁纸层需要位于系统壁纸层与桌面图标层之间。最终取值为-2147483610，比图标层低7层。

设置中存在名为“壁纸盖住桌面图标”的开关。

4K视频持续解码，需要在电池供电时暂停。电池状态通过IOKit获取：调用IOPSCopyPowerSourcesInfo获取电源信息列表，读取kIOPSPowerSourceStateKey；若其值等于kIOPSBatteryPowerValue，则判定为电池供电。

全屏模式检测不使用辅助功能。改为遍历窗口列表中layer == 0的窗口，取叠放顺序最靠前的窗口，计算其与屏幕的交集面积；若覆盖面积超过98.5%，则判定为全屏。

遮挡检测同样遍历窗口列表，但选项不同。窗口列表按叠放顺序提供，索引越靠前表示层级越高。因此需要查找位于壁纸窗口之前、layer >= 0且覆盖面积超过98%的窗口。此处不能添加.excludeDesktopElements；添加后会将壁纸窗口本身过滤掉，导致遮挡检测始终返回未被遮挡。全屏检测可以添加该选项，因为该场景本应忽略桌面层。

锁屏和屏幕休眠通过通知处理。在DistributedNotificationCenter上监听com.apple.screenIsLocked和com.apple.screenIsUnlocked，并在NSWorkspace上监听screensDidSleep和screensDidWake；事件到达时立即置位。电池和全屏状态每2秒轮询一次，仅在状态实际翻转时回调。

满足暂停条件时，日志记录一行“暂停播放（全屏应用 / 电池供电）”，并并列列出原因。

每块屏幕对应一个独立的NSWindow，通过遍历NSScreen.screens完成创建。插拔显示器或更改分辨率会发送didChangeScreenParametersNotification，且一次操作会连续发送多次；因此增加0.6秒防抖后再重建。

切换Space或激活其他应用后，偶尔会出现窗口不在当前Space的情况。在didActivateApplicationNotification和activeSpaceDidChangeNotification之后延迟0.35秒再次调用orderFrontRegardless。该数值经实验确定；若延迟更短，系统尚未完成窗口位置调整。

倍速

AVPlayer在2×以上存在硬性上限。使用macOS自带Aerial航拍素材测试（3840x2160、HEVC Main 10、239.76 fps），2.0×可稳定达到120帧/秒；调整至2.2×后降至每秒0至1帧，AVPlayerItem.canPlayFastForward也为false。仅相差0.2×即完全停止。

规避方法是将倍速预置到时间轴。使用AVMutableComposition将整段视频scaleTimeRange压缩至1/倍速 的时长，播放器仅以1×播放。

1
2

let compressed = CMTimeMultiplyByFloat64(asset.duration, multiplier: 1.0 / speed)
track.scaleTimeRange(full, toDuration: compressed)

时间轴压缩后，修改倍速必须重建内容，而重建会导致播放进度归零。修正方法是在重建前记录源视频进度（currentTime × bakedSpeed），重建后seek到position / factor。

另有一个较不显著的问题：将“是否需要预置倍速”表示为布尔值并纳入配置指纹。3×、4×、5×均对应true，配置签名不变，因此不触发重建，始终按首次的3×播放。改为比较实际倍速值后行为正确。

重建还会导致短暂黑屏。replaceCurrentItem会清空图层缓冲。先移除旧层再创建新层，期间必然出现黑屏。使用旧层快照进行遮挡也不可行，因为AVPlayerLayer.contents恒为空，播放器不通过该通道输出。

最终采用双缓冲。保持两个(AVPlayer, AVPlayerLayer)实例，在不可见实例上更换item、执行seek并开始播放，轮询直到isReadyForDisplay为真且时间轴推进（最多等待1秒），然后交换可见性；此时才暂停旧实例并调用replaceCurrentItem(with: nil)释放解码器。轮播切换复用同一路径，手动“下一幅”同样不会出现黑屏。

另有一处与倍速相关的问题：AVPlayer.play()等价于rate = 1.0，因此先设置rate再调用play()会覆盖速度。表现为初始速度正确，但暂停后恢复时速度变为1×。所有起播路径统一改为playImmediately(atRate:)。

高倍速下卡顿是另一类问题。4×下出现周期性卡顿。最初认为由解码能力不足导致，但实测时间推进准确，CPU占用仅2.3%。实际原因是帧生成速率与上屏速率不匹配：30 fps素材在4×下需要120帧/秒，而AppKit窗口默认不以ProMotion的120 Hz满速运行，需要显式申请。macOS不提供CALayer.preferredFrameRateRange，该API属于iOS；只能使用NSView.displayLink。声明后可通过回调频率验证，日志可输出display link实测120.5 Hz。

5×属于物理限制。30 fps素材在5×下需要150帧/秒，120 Hz屏幕最多显示120帧/秒，必然丢帧。设置界面按“屏幕刷新率 ÷ 源帧率”计算该素材的最高无损倍速，超过该值时以橙色标记，无需逐档测试。

开机自启

开机自启配置写入~/Library/LaunchAgents/com.chenxinyu.lumina.plist。其中ProgramArguments包含--autostart，设置RunAtLoad，并将LimitLoadToSessionType设为Aqua。执行bootstrap前先执行一次bootout；否则重复切换自启开关时会返回service already loaded。

应用采用ad-hoc签名（codesign --sign -），不包含开发者证书。用户下载并解压后，Gatekeeper会拦截。处理方式有两种：在“系统设置 → 隐私与安全性”中选择“仍要打开”；或执行xattr -dr com.apple.quarantine /Applications/Lumina.app。该操作应在构建脚本中一并执行。

此外，将.app组装在mktemp创建的临时目录中，项目内仅保留zip文件。macOS 26的App库依据LaunchServices注册表收录bundle；只要项目目录中曾出现.app，就会与/Applications中的副本共同注册，导致显示两个图标。

「一份 RLE 指北」

Real Life Experience实际生活体验。

欢迎大家来到 RLE.wiki. 这是一份给跨性别者与性别多元群体的 RLE 指南。更多帮助正在路上，敬请期待……

笔者从X得知的这个项目。在翻它的校园栏目的时候。有着一百七十多个学校，大部分城市都能翻出几条。但是没有我的大学。

怎么可以没有大农专！我写！

写了docs/campus/NJAU.md，162行。开头一张总览表，规则是情况正面用✓、负面用✗、不确定用?、视情况而定用-。

PR挂上去没多久，Twinsherry在下面留了句话，说LS-KR之前已经从这里撤过一次南京农业大学的条目，作为数据遗产资料的继承人，她希望把旧版本里LGBT相关的部分补进来。

我当天问了旧内容能在哪个commit或者归档仓库里查到，她给了个链接，PR 586，标题「doc: rm NJAU」，2025年5月合并的，改一个文件，纯删85行。

我一开始就是知道的，那是学姐。只是她后来想不开了，走之前rm了南农相关的文章。git历史我也是看到了的

旧版本能找到的东西就是那段差分里剩下的全部。

其中的LGBT内容和校内医疗相关的说法挑出来，一部分并进正文，部分核实不了的用::: details 旧版资料折叠起来挂在对应小节下面，标注了是上一版投稿人的描述。

::: details旧版资料：上一版投稿人对宿舍搜查的描述（笔者没遇到过，认为是特殊情况，予以保留）

辅导员或学院或学校会定期秘密地搜查学生的宿舍，频率为一个学期至少两次。同班所有人的物品均有被翻动的痕迹。
笔者从医院回到宿舍时发现自己的电脑已经是只剩一次机会否则全盘加密锁定的状态。
没有藏好的糖（还需要吃的那些）也被收走。
带锁是必须的，不要用密码锁。

:::

我没法验证。校医院能不能测六项、益丰大药房有没有可能出现二十多块一盒的补子。

第二个提交f33b805改了59行删了24行，把那张总览表重新排版对齐，另外补了几处我当时想起来的细节：军训16天、后半程有晚训、每天三个时段分性别训等等。

审稿尺度

投稿指南里定的尺子很具体。

1. 不得修改模板中的二级标题，如果认为不需要填写该项目，请注释掉。markdown的注释语法为<!-- -->，例如<!-- ## 其他信息 -->。
2. 如有必要，可以自由添加多级标题。
3. 为了观察方便，英文与汉字之间需要添加空格，例如例子 example 例子。
4. 专有名词缩写注意大小写，例如MtF，具体可以参考https://mtf.wiki/zh-cn/docs/useful-info/abbreviation/。
5. 主观内容请使用引用格式，例如> 引用内容。
6. 句末需要加上中文句号。。
7. 如果有引用到静态文件，例如图片视频等，请在docs/assets目录下上传图片（以文档名开头），并在markdown文件中使用相对路径的方式引用。例如我的文档名为example.md，在其中引用一张名为Test.png的图片，那么我需要将Test.png改名为example_Test.png，上传在docs/assets目录下，然后在markdown里面使用![](/assets/example_Test.png)的方式引用。
8. 对于过时内容的处理：
   • 影响力持续至今的事情，尽管其已经结束，但为了因果关系完整，仍应予以保留。（举例：2020年，某校因为COVID-19疫情防控措施而取消了某政策，至今没有恢复，但由于2022年12月的防控措施变化，而在近期存在恢复可能的，在等待两年（至2024年12月）、排除其恢复可能后，将“以前的政策”和“受COVID-19疫情防控措施影响”这两句按下方处理）
   • 已无影响力，但影响力消失不足两年的，予以折叠、标注过时（使用:::details :::语法）。
   • 已无影响力，影响力消失满两年的，予以删除。

部署

PR一开就有bot来贴预览地址，，每个PR独占一个Cloudflare Pages部署，改完刷新就能看到修改完的界面是什么样。

好高级！我都不知道GitHub居然还能这样

想练SQL一直卡在环境上。在线基本只有长文教程，本地装个数据库又麻烦，适配性不强。不如自己写一个：纯静态页面，双击HTML就能用，离线使用。

现在有50关，从SELECT一路排到递归CTE。每题写真正的SQL，由SQLite执行后比对结果集，对了才放行。

仓库在4choor3/sql-quest，在线版https://4choor3.github.io/sql-quest/。

底子

sql.js把SQLite编译成了WebAssembly，查询全在浏览器本地跑，数据不出机器。

麻烦在分发。常规做法是一个index.html加一堆js再加个640KB的.wasm，还得起HTTP服务——file://下fetch拿不到本地文件。我把wasm转成base64塞进js，npm run build出一个1.2MB的sql-quest.html，依赖全在里面。base64会让体积涨三分之一，换来的是不用起服务，值。

题库

基础篇是书店业务：作者、书籍、客户、订单、订单明细五张表，25本书、30笔订单。数据里埋了几个坑。有个客户从没下过单，练LEFT JOIN的时候正好拿来分辨COUNT(o.id)和COUNT(*)——后者会把没订单的那行数成1。有本书的genre是NULL，IS NULL和相关子查询里的IS（不是=）都得用它。订单有已完成、已取消、待付款三种状态，聚合之前不先过滤就算错。

进阶篇换成校园选课，也是五张表，但courses.prereq_id指向同一张表的id，自连接和递归CTE有真实的层级能展开。另外特意留了5个一节课都没选的学生，不然NOT EXISTS这类题没有正确答案。

进阶关不难在语法，难在组合。表一多，得自己想清楚从哪张出发、怎么连过去；而且多半要拆两步，先算中间结果再基于它算答案。

判题

答案写法定不下来，没法做文本比对。每关存一份参考SQL，运行时现场算出期望结果，再和你的结果比。四种比法：columns是列名加无序行集合，ordered要求行顺序也对，set只看行集合，scalar比单个数值带浮点容差。

不通过时给差异清单。测COUNT(*)那个坑的时候，面板直接列出「冯磊0」和「冯磊1」两行，比说一句答案错误有用得多。

另外加了关键字约束。题目要求用LEFT JOIN，你写死WHERE name = '冯磊'凑答案会被拦下。结果对了，但这题就白做了。

编辑器

一开始就是个textarea。后来想加高亮和补全，发现两个都不好办。

高亮最后做成了「文字透明的textarea叠在一层<pre>上面」。选区、光标、输入法都还是textarea的原生行为，看到的高亮来自底下那层。两层必须像素对齐，否则文字会重影，所以排版规则只写一处、两层共用，另外textarea用scrollbar-gutter: stable常驻预留滚动条槽位，高亮层补上同样的右内边距，两层的内容盒才等宽。测试里卡的是内容盒宽度、scrollHeight和13项排版属性全等。

补全要贴着光标弹，得先知道光标在textarea里的像素坐标。用了个镜像div：复刻textarea的计算样式，把光标之前的文本灌进去，再插一个span量它的位置。好处是字号改了自动跟随，不用改代码。

排序按光标位置分。语句开头给关键字（sel → SELECT），FROM或JOIN后面给表名（bo → books），查询中段给列名（st → stock），打了b.就只给books的列。别名也认：写了COUNT(*) AS book_count，后面打book_co能补出来；WITH city_stat AS (...)之后能补CTE名；派生表后面打b.ti，能从内层SELECT推出title。

格式化用sql-formatter。全量包312KB，带20多种方言，这项目只用SQLite，就写了个esbuild插件把方言注册表换成只含sqlite的版本，压到57KB。

几个坑

WASM实例那块最要命。切关卡要恢复到该关的初始状态，我最初的写法是这样：

1
2
3

const old = this.db;
this.db = new this.SQL.Database(snapshot);
old.close();

this.db平时就是数据集注册表里的常驻实例，把旧的关掉，那套数据就永久废了——之后任何查询都抛ErrnoError: FS error，而且不可恢复。这个bug只在反复跨数据集切换时才触发，只做一套库的话永远碰不到。改成原地替换注册表引用就好了：新实例顶上，注册表指向新的，再关旧的。

CSS表格一次踩了仨。

max-width对table cell不生效。我给td设了max-width: 320px想截断长文本，实测宽度360px。CSS 2.1里这个属性对表格单元格就是没用，最后把截断压在内层元素上。

数值列右对齐好看，但表头默认左对齐，两者能差50px以上。得先按列判断是不是数值列（该列所有非空值都是数字），给th和td加同一个class才对齐。这个问题之前一直没被测出来，因为我的几何断言只比了单元格盒子的坐标——盒子当然对得齐，但文字能差一大截。后来改用Range量文字的实际位置，按对齐方式比对应边缘。

还有width: 100%会把多余空间按比例摊给每一列。id列内容只要40px，被撑到90px，看着间距很怪。改成让最后一个文本列吸收剩余宽度——文本列变宽只有好处，数值列变宽只会让数字贴着右边、中间空一大截。

还有个正则在补全里作祟。在FROM orders o JOIN o后面打下去，候选里给的是order_date（一个列名）、ON、OR、ORDER BY，偏偏没有orders。

原因是我用一条正则从第一个FROM开始匹配：

1
2

FROM orders o JOIN o
└──── 整段被吞掉 ────┘

JOIN落在被吞掉的部分里，被当成「这个子句里已经有别的关键字了」，于是判定失败、退化成列名上下文。改成取最后一个引导词再往后看就行。顺带把表名位置的候选也收干净了——那儿本来就只有表名合法，现在JOIN order_d干脆什么都不给，而不是递上一个order_date误导人。

测试

这类工具有个麻烦：错了不一定看得出来。所以写了一套脚本，改完必跑。verify检查50关的参考答案能不能过自己的校验、起始代码会不会被误判成通关；e2e是浏览器端到端的46项；editor管格式化、补全、高亮那56项；fullplay把50关在浏览器里逐个打通；offline验单文件版在file://加断网下能不能跑。

最后一个是这次新加的：live，部署完实测线上站点能不能真答题。之前只看HTTP 200就以为发布成功了，其实接口通了不代表页面能跑。

仓库

代码、题库、两套示例库都在4choor3/sql-quest。不构建也能用，dist/sql-quest.html下载下来双击就开，放U盘或者发给别人都行。两套库也单独导出了dist/bookstore.sql和dist/campus.sql，可以拖进DBeaver自己练。MIT协议。

主题做了深浅两套，浅色不是简单反色，强调色压暗到#9a6200，六类语法色在白底上的对比度都在4.8:1以上。

拿它做点能跑起来的东西，配了一块1.8寸屏：屏幕、电池、主控、充电板。

项目开在4choor3/rp2040-txt-reader，接线表在hardware/PINOUT.md，带图的分步制作指南在docs/BUILD_GUIDE.zh-CN.md。

选型

对于板子的选择：

选RP2040最为方便：插上线就是U盘，驱动装一次就识别、不用开热点、不用编译器。

物料清单

自己焊接的话，主控要买未焊接排针的散件版，屏幕需要焊接好的，不能是裸板。

结构

屏幕（最底层，屏面朝外）→ 缓冲层 + 电池（中层）→YD-RP2040 + TP4056（顶层）

主控53.3 × 22.9 mm能放在约56 × 34 mm的屏幕背后，电池夹在中间。

缓冲层

屏幕背面有LDO、贴片阻容，有的批次还带SD卡座，凸起1–2mm。软包锂电池皮很薄，不能直接压上去。需要垫一些软的中层。

焊接

先拆掉排针

如果收到板子后者屏幕是已经焊好排针的版本，需要先拆下排针：

1. 用斜口钳或尖嘴钳夹碎排针底部的黑色塑料座，让金属针彼此独立。
2. 一手镊子夹住一根针，一手用电烙铁加热背面的焊点；锡化啦就轻轻往外抽。
3. 吸锡器吸净孔内残锡，或者用牙签趁热捅穿——孔必须通透，后面要穿线。

屏幕接线

剪8根约5cm的30AWG硅胶线，分别穿过屏幕底板那8个孔（VCC、GND、SCL、SDA、RES、DC、CS、BLK）焊死。

电源链路

电池红线焊TP4056的B+，黑线焊B−。这两根正负极不能接反或短接。

接着OUT+出来先过拨动开关再过主控Vin，OUT−接主控GND。

飞线对接

把屏幕上焊接的8根线从电池侧边翻上来，一根一根焊到主控对应引脚上。每焊一根都先比划长度：剪掉多余的、重新剥皮再焊，保证线贴着电池边缘走、不拱起来。

全部接完就是文章开头那张图的样子。

按键

两个按键各自的一个引脚并联起来接GND，另一个引脚分别接GP16 / GP17。主控内部上拉，按下即拉低触发，不占地方也不用额外元件。

接线表

屏幕（1.8寸ST7735，走硬件SPI1）

板上通常只引出一个3V3孔，接两根线不方便。做法是在屏幕端把VCC和BLK短接，并联后共用一根飞线接到3V3，最整洁。

电源链路（电池 → 充电板 → 开关 → 主控）

翻页按键

通电前检查

拨开关之前确认这几处：

• 剪断的金属废线头全部清理干净，没有掉进任何板子缝隙里。
• 从底板翻上来的导线外皮完好，没有被板边锋利焊盘割破露铜。
• 电池与任何金属针脚、焊点之间都有绝缘（双面胶或硬塑料片），没有被刺穿的可能。
• 有条件就上万用表蜂鸣档：该通的关键引脚确实通，相邻引脚没有意外短路。

上电

接线正确、固件也烧好之后拨开关，屏幕会亮起来打印启动信息——这台跑的是CircuitPython 10.3.0，画面里的提示文字是固件自带的拼音化中文。

屏幕上出现字，说明SPI那五根线、复位、片选和供电正确。

屏幕是彩屏，能显示标准24位BMP图片，仓库里examples/image_viewer.py可做测试。

放文件：插上线就是U盘

1. Type-C线插设备连电脑，会弹出一块名叫CIRCUITPY的U盘。
2. 把UTF-8编码的book.txt拖进盘根目录，拔线。
3. 拨开关开机，按「下一页」从第一页开始读。

充电时线要插在TP4056的Type-C口，插主控口是直接给主控供电，不走充电板。

固件

板子跑的是CircuitPython（仓库：adafruit/circuitpython）。屏幕驱动、中文字体、翻页逻辑一共216行，另外依赖三个库，都在Adafruit的仓库里：

• Adafruit_CircuitPython_ST7735R — 屏幕底层驱动
• Adafruit_CircuitPython_Display_Text — 文本排版
• Adafruit_CircuitPython_Bitmap_Font — 加载点阵字体
• 想一次拿齐，用官方合集Adafruit_CircuitPython_Bundle

中文用的是BDF点阵字体，文泉驿点阵宋体有现成的中文字形可以转。

注意：

• CircuitPython 9.x起FourWire从displayio拆成了独立的fourwire模块，照8.x教程写会报AttributeError，表现是背光亮但屏幕全黑——很容易误判成焊接问题。
• 这块屏的色序是BGR，建display时要显式bgr=True，不设颜色会反。

仓库

完整制作指南（选型 → 烧录 → 组装 → 排障）在docs/BUILD_GUIDE.zh-CN.md，接线表在hardware/PINOUT.md，代码与示例在仓库根目录。MIT协议，欢迎照抄。

第一版：Hugo

Hugo用Go编写，安装是一个二进制文件，放进PATH即可使用，不需要Node环境。全站一个配置文件，文章按目录组织，主题放在themes目录（直接放或用git submodule管理）。front-matter支持TOML、YAML、JSON三种格式。当时用的版本是0.165.0。本地预览是hugo server，生成是hugo，输出在public目录。

1
2
3
4
5
6

content/
  posts/
    2026-09-08-hello-world.md
themes/
  PaperMod/
config.yml

主题是PaperMod，自带排版、深色模式、目录（TOC）、代码高亮和搜索。星空背景、鼠标点击特效、访问统计不在主题里，需要自己写CSS和JS挂在主题外面。这几个效果要维护的代码量接近主题本身。所以换掉了。

第二版：Astro

Astro属于Node生态，用npm装依赖，配置文件是astro.config.mjs，构建输出到dist目录。

1
2
3
4
5
6
7
8

src/
  content/
    blog/
      hello.md
  layouts/
    BlogPost.astro
astro.config.mjs
package.json

内容集合是它的一个机制：文章的front-matter字段在TypeScript文件里定义，不符合schema的字段会在构建时报错。输出默认不含前端框架的JavaScript，需要交互的组件单独声明。本地预览是npm run dev。

日常使用上，改配置后要重新执行npm install和npm run build，node_modules目录装下来几百兆。所以换到了Hexo。

第三版：Hexo

Hexo属于Node生态，当前版本8.1.2，主题是开源的安知鱼（anzhiyu），版本1.7.0。

1
2
3
4
5
6
7

source/
  _posts/
    2026-09-08-hello-world.md
themes/
  anzhiyu/
_config.yml              # 站点配置
_config.anzhiyu.yml      # 主题配置（站点级覆盖）

配置两层：站点_config.yml管生成与目录参数，_config.anzhiyu.yml管外观和功能开关。新建文章用hexo new，本地预览用hexo server，生成用hexo generate，输出在public目录。主题自带星空背景、鼠标点击特效、首页打字机、本地搜索、字数统计、访客统计、深色模式、繁简转换、版权声明、音乐页、分类标签归档页、图片灯箱、相对时间，都在主题配置里开关，不用自己写代码。其中本地搜索由生成search.xml、前端检索实现，不依赖外部服务。

默认字体是霞鹜文楷，文章支持封面图、置顶、分类和标签。背景粒子和首页头图自写脚本放置。定制放在_config.anzhiyu.yml里，主题更新不受影响。

三个引擎的产物都是纯静态文件，HTML加CSS加JS，不需要服务端。

120台为早期CPU节点，双路32核Xeon 8358P，单机64核 / 500G内存，承载日常主要算力。数台胖节点为四路24核Xeon 8360H，单机96核 / 2T内存，供大内存作业使用。最新批次为GPU节点，单机96核 / 1T内存、8张H20，另有一台配2块4090。另有2台国产K100异构节点，自五月末起持续offline。

平台另有二十余台GPU机器未纳入SLURM节点列表；登录、管理、监控类机器同样不计入调度器口径，sinfo不显示。

主要用户方向为生物信息与计算化学，module avail提供87个模块，blast、bwa、vasp、gromacs占多数。

登录节点仅承担登录与作业提交，计算须下发至计算节点。调度系统版本SLURM 23.11.10，以下数据均在登录节点实测采集。

节点详情

1
2
3
4

sinfo -s                             # 分区概览：节点数、状态分布
sinfo -N -o "%N %P %c %m %G %t"      # 逐节点：核数、内存、加速卡、状态
squeue -o "%.8i %.8P %.18j %.8t %.10M %R"    # 自己的作业
sacct -u $USER --starttime=now-2hours        # 自己的历史作业与资源用量

sinfo -s输出：

1
2
3
4
5
6
7
8
9
10
11

PARTITION AVAIL  TIMELIMIT   NODES(A/I/O/T) NODELIST
cpu96        up   infinite          1/4/0/5   fat[01-05]
cpu64*       up   infinite        25/95/0/120 node[01-120]
test96       up   infinite          0/2/0/2   node[121-122]
soy-com      up   infinite          0/22/0/22   sri-com-[01-22]
sri-com      up   infinite      13/1/0/14     sri-com-[23-36]
sri-mem      up   infinite          0/2/0/2   sri-mem-[01-02]
sri-ghz      up   infinite          0/2/0/2   sri-ghz-[01-02]
sri-gpu      up   infinite          0/1/0/1   sri-gpu-01
sri-gnm      up   infinite          0/1/0/1   sri-gnm-01
dcu          up   infinite          0/0/2/2   dk-gpu[01-02]

带星号的cpu64为默认分区，不指定-p时作业落入此分区。中间四列为allocated / idle / other / total。

分区

十个分区合计171台、12352核。cpu64中118台为500G内存，其余两台384G。

sri-*一组绑定专属QoS，普通账号提交返回Invalid qos specification，CPU型号无法读取；dcu两台offline，同样无法读取。

cpu64的120台为主力：空闲95台时可直接提交；25台在跑时backfill仍可插入空闲窗口。调度器记录内存500G，节点内free -g实测503G。

DCU两台装国产K100，sinfo中为down*，scontrol show node给出的原因为Not responding，自五月底持续至今。另两台带加速卡的节点——sri-gpu的H20与sri-gnm的4090——位于上述受限QoS组内。

系统代际存在差异：早期CPU节点为CentOS 8.2 / 内核4.18，后加的GPU与内存节点为RHEL 9.5 / 内核5.14。/hpc/software下gcc覆盖4.8.5至14.1.0，glibc保留2.29与2.36两套，对应两代系统各留一版。自行编译的二进制跨分区搬运存在兼容风险。

作业提交

交互式调试用srun：

1

srun -p cpu64 -N1 -n1 --time=00:30:00 --pty bash

实测分配到node08，grep -m1 'model name' /proc/cpuinfo为Xeon Platinum 8358P。进入后nproc返回1而非64——srun该步仅分配1个CPU，确认整机规格需读/proc/cpuinfo或使用lscpu。

正式任务写脚本交sbatch：

1
2
3
4
5
6
7
8
9
10
11

#!/bin/bash
#SBATCH -J quant-backtest
#SBATCH -p cpu96
#SBATCH --cpus-per-task=32
#SBATCH --mem=256G
#SBATCH --time=08:00:00
#SBATCH -o /hpc/home/%u/logs/%j.out
#SBATCH -e /hpc/home/%u/logs/%j.err

cd ~/quant
python backtest.py

申请加速卡加一行#SBATCH --gres=gpu:1，具体型号见分区Gres字段。

集群SelectTypeParameters为CR_CORE，调度按核数分配，内存不参与资源分配——作业不写--mem亦可运行，节点AllocMem恒为0。以两个1核作业验证，运行期间所在节点AllocMem均为0。同节点多作业之间互不可见实际内存占用，先占满内存的作业会影响其余作业，故提交时须显式指定--mem。sacct中ReqMem显示500000M，为未填该字段时按节点总内存回填的显示值，不代表实际申请整机。

数组作业上限MaxArraySize为1001，单次最多提交1001个子任务，更大规模需分批提交。

调度器按什么排

PriorityType = priority/multifactor，SchedulerType = sched/backfill。前者按作业年龄、份额、队列权重计算优先级，后者负责插空——作业若能在一个空闲窗口内跑完，即可提前启动。

该组合利于短作业，反向亦然：为一个5分钟的任务写--time=72:00:00，backfill找不到足够长的窗口，作业只能排队。

所有分区时间上限均为infinite，MaxTime无系统级限制，时限交由使用者自行声明，长时作业可长期占用节点。

squeue -a在普通账号下不显示其他用户作业：实测squeue -a -h | wc -l返回0，同一时刻sinfo显示25个节点处于alloc状态。判断集群负载只能依据sinfo的节点状态分布。

存储：23P与5000亿inode

df -hT中容量最大的一行：

1
2

Filesystem      Type      Size  Used Avail Use% Mounted on
/hpc             dpc        23P  1.1P   22P   5% /hpc

23PB并行文件系统，已用1.1PB。文件系统类型为dpc，属分布式存储客户端挂载，与本地盘行为不同——小文件随机读性能与顺序读写相差量级，登录节点禁用du / find即源于此。

inode容量见df -i /hpc：总量5000亿，已用2.33亿。元数据按目录树铺开、查询需走网络，是该量级的成因。

另两个挂载点：

• /usr/local/globle/softs为NFS，191G、59%已用，存放slurm二进制与公共软件，所有节点共享同一份。
• /dev/shm为252G内存盘。数据管道中间结果置于此处，读写不落盘；重启即清空。

家目录位于/hpc/home/<用户名>。以本账号为例，占用接近48TB，主要为从ModelScope拉取的49个模型，其余为量化日线数据。

环境与启动速度

公共软件通过module加载，module avail挂载87个：生信类（blast、bwa、hmmer、canu、megahit、gtdbtk、metawrap）、计算化学类（vasp、gromacs、amber、autodock）、gcc/4.8.5至gcc/14.1.0、openmpi 3.1至5.0.5、cuda/11.7与12.4、Python 3.7/3.8、R三个版本、singularity两个版本。使用前module load gcc/14.1.0 openmpi/5.0.5即可，优于在home内自行编译。

Python环境采用miniconda，按用途拆为四个：myenv放通用工具，quant放baostock相关依赖，agent与agent-gpu分开的原因是GPU侧依赖锁定在另一cuda版本。

zsh启动时间做过专项优化。原始耗时约15秒，成因是oh-my-zsh及插件每次登录重新source，而home挂在分布式存储上，网络文件系统随机读延迟高。处理办法是把omz与历史文件缓存到/dev/shm，并将"重新加载配置"改写为跳过omz重复加载的函数。优化后约0.8秒，多终端窗口并发打开时差异明显。

长任务用tmux托管

登录节点直接运行长任务，网络断开即进程终止，改用tmux托管：

1
2
3

tmux new -s pull        # 建会话
# Ctrl-b d 脱离
tmux attach -t pull     # 重新接上

集群tmux版本为2.7。小时级以上的任务交sbatch；tmux用于托管数据拉取循环与监控进程。