最近我在干什么 #8
面对 Next.js 动态博客页面加载缓慢的问题，作者设计了一套自定义缓存方案。该方案能在特定时段内避免重复请求，通过访问触发后台更新，确保内容即时呈现且无延迟。当内容超过约一个月无人访问时，系统将强制刷新。同时集成了 Gist 的最终更新机制，进一步提升响应速度。
缓存命中率提升的效果大家有目共睹，不是吗？
不过这套系统尚未经过完整测试，我对深夜赶工的设计方案其实心存顾虑，只能静观其效。
如今两周过去，运行状况良好！在此期间可能各位已注意到，我们正式弃用了旧的 zhenghuo 存储。因其包含大量 JSON 与压缩文件，非纯文本格式已不适用 GitHub 生态。
新建的存储体系基于 S3 代理与 miniserve 构建。S3 代理层让我能通过标准 S3 接口操作文件系统，既然现有程序支持本地到远程 S3 的同步，何不物尽其用？更何况 S3 本就是行业标准！
miniserve 作为轻量级文件分发服务，界面简洁明了。虽然 Apache 风格服务本是首选，但考虑到 Nginx 潜在的安全隐患，最终选择了功能契合的 miniserve——它甚至支持通过 .tar.gz 打包下载完整目录！基于流式处理的特性也确保了内存高效利用，压缩率并非重点，核心在于完整的目录下载功能。
我将边缘节点缓存时长设为 6 小时。存储中的文件可能随时间变更，包括目录视图、文件及目录压缩包都会因版本迭代或问题修复产生变动，因此缓存周期不宜过长。面对突发流量，借助 Cloudflare CDN 分流是理想方案，毕竟这类内容本质上并非高度动态。
通过 Nginx 替换默认 favicon.svg 的过程颇费周折。由于站点经 Cloudflare 隧道连接，我新建了监听不同端口的服务节点，却发现 nginx -s reload 无法完全生效。配置重写规则时，智能助手提醒我：切勿删除重写模块中的 break 指令！它解释道：首段重写会触发重新加载，跳过初始模块后由第二段进行代理... 虽然最终生效，但可能存在未知异常。
于是我移除了重写规则中的 break 指令。
上传文件时发现，IPv4 证书的签发机构未被 Python 与 OpenSSL 信任库收录，这解释了为何使用 Mac 的同学连接服务时会收到安全警告。虽然此前说明过原因，但值得再次重申：
我的多数服务都经由 Cloudflare 代理，但某些场景下直连速度确实...
由此可见技术记录的重要性。直接通过 IPv4 访问并非最佳选择，Cloudflare 在本市设有边缘节点，实际速率影响有限。
这个问题我会尽快解决。
riscv-mc 模拟器项目近期取得显著进展：终端界面趋于完善，键盘交互体验优化，并实现了阻塞式读取系统调用（实际环境中默认为阻塞模式，相关库也是基于此设计，若模拟器未遵循该特性会导致异常）。
相关演示视频将于近期发布。
我也想当java大佬{:XDPB:} nicocat 发表于 2025-11-22 22:49
我也想当java大佬
这篇帖子没提半个字的java{:XDPB:} 最后的图片给我整乐了。。。 WisW 发表于 2025-11-22 23:35
这篇帖子没提半个字的java
next.js用了javascript，javascript里有java，所以这篇帖子说到了java
页:
[1]