我的博客被完整地反向代理，并自动翻译成了繁体中文
2024.08.20更新我将境外的 Github Pages 解析停了，所有流量全部指向我的 HK 的 vps。 访问对方站点 /?about/ 时，在我服务器 /about/ 收到了一个奇怪的请求，访问对方别的路径时也会在我服务器的对应路径收到请求，UA 伪装成了 Google 家的爬虫: （关于为什么有 Mozilla 字段，可以参见 《是的，所有现代浏览器都假装自己是火狐》） 这个 ip
2025 年，如何为 web 页面上展示的视频选择合适的压缩算法？
事情的起因是需要在网页上展示一个时长约为 5 分钟的产品展示视频，拿到的 H264 编码的原文件有 60MB 大。高达 1646 Kbps 码率的视频文件通过网络传输，烧 cdn 流量费用不说，对于弱网环境下的用户体验也绝对不会好。因此必须在兼顾浏览器兼容性（太好了不用管 IE）的情况下，使用更现代的视频压缩算法进行压缩。 哪些压缩算法是目前的主流？AV1AV1 作为目前压缩效率最高的主流视频编码
el-image 和 el-table 怎么就打架了？Stacking Context 是什么？
这是精弘内部的图床开发时遇到的事情，大一的小朋友反馈说 el-image 和 el-table 打架了。这里专门提供一个 demo 来直观展示情况，下面是截图。 看到后面的表格透出 el-image 的预览层，我的第一反应是叫小朋友去检查 z-index 是否正确，el-image 的 mask 遮罩的 z-index 是否大于表格。 经过我本地调试，发现 z-index 的设置确实没问题，但
2025年，前端如何使用 JS 将文本复制到剪切板？
基础原理如果你尝试在搜索引擎上检索本文的标题，你搜到的文章大概会让你使用下面两个 API。我希望你用的搜索引擎不至于像某度一样灵车到 2025 年还在让你使用基于 Flash 的 ZeroClipboard 方案 document.execCommand2012 年不止有世界末日，还有 IE 10。随着 IE 10 在当年 9 月 4 日发布，execCommand 家族迎来了两个新的成员—— c
ssh 拯救世界——通过 ssh 隧道在内网服务器执行 APT 更新
事情的起因是因为精弘的前技术总监抱怨学校的内网服务器无法连接外网，从而导致 apt 安装与更新异常困难，需要手动从源中下载软件包、软件包的依赖及其依赖的依赖。。。然后将这些包通过 sftp/rsync 一类的手段传到服务器上手动安装。 于是本文应运而生，我们可以在本机使用 Caddy （Nginx 当然也行）反代一个 APT 源镜像站，通过 ssh 隧道建立端口转发，这样就可以在内网服务器上访问
Cudy TR3000 吃鹅(daed)记
缘起前不久在京东自营看到我馋了很久的 Cudy TR3000 有 ￥153 的折扣价，虽然比起 ￥130 的史低价（甚至 ￥110 的凑单史低价）还有些距离，但已经到我的可接受范围内了，于是果断下单剁手了这台我心心念念的 Cudy TR3000 迷你路由器，以此来缓解我的开学前综合症（一种精神性疾病） 这台路由器使用 Type-C 供电，拥有一个 2.5Gbps 的 WAN 口和一个 1Gbps
使用 Cloudflare Workers 监控 Fedora Copr 构建状态
确信，是 cloudflare workers 用上瘾了 在「使用 Github Action 更新用于 rpm 打包的 spec 文件」一文中，我利用 Github Action 实现了自动化的 spec 版本号更新，配合 Fedora Copr 的 webhook 就可以实现 Copr 软件包更新的自动化构建。看似很完美，但缺少了一个构建状态的监控机制，这导致出现构建错误的时候我不能及时得
基于 Cloudflare Workers 实现的在线服务状态检测告警系统
起因受一些客观因素的影响，微精弘前一阵子针对学校教务系统的数据爬取服务状态出现了非常不稳定的状态，而后端在设计初并没有考虑到异常告警机制，恰逢现任员工都身陷期末周的痛苦之中，我这种计院 Lite 专业的精弘老人就打算实现一个针对「微精弘主后端 <-> funnel 爬虫服务 <-> 教务系统」这一条链路的告警机制。旨在短期内（即期末周结束之前）填补微精弘的后端服务告警机制