Allen Hua 的网络博客 - Allen Hua
type: channel
link: https://hellodk.cn/author/1/
description: Allen Hua
items: 给机械革命钛钽plus换屏：NY2换成NZ2
items: 记录一次pve宿主机和上面的debian虚机无故down机事件
items: 给图床部署cdn腾讯云的edgeone并排查Cache-Control max-age 3600的问题
items: 从高山草甸到徽派古村：武功山反穿与皖浙赣自驾行记
items: 增程器就是充电宝？别被忽悠了
items: 浦口龙虎巷扫街，记录人间真实
items: 博客图片压缩方案更新｜AVIF｜WebP｜MozJPEG｜标准JPEG
items: Windows 电脑使用 Obs Studio 录制各个网站视频/桌面画面教程
items: 为typecho博客添加latex支持
items: 新能源汽车之纯电车使用交流慢充和直流快充的充电损耗对比

给机械革命钛钽plus换屏：NY2换成NZ2
type: item
date: 2025-09-13T23:41:00+08:00
description: 本文记录给我的机械革命钛钽PLUS换屏。 旧屏幕用了将近4年（2021年6月购入），今年花屏（几月份来着，不记得了，这不重要），然后全黑，最后怎么都不亮了。我外接了两块显示器使用，一根使用 typec to hdmi 接入显示器，另一根使用 hdmi to hdmi 接入显示器。最近准备给这个电脑换一下屏幕，了解到机革同年甚至22年几个系列都喜欢用京东方 NY2 屏幕，网上能搜到很多翻车信息。 哔哩哔哩这两个视频评论区有很多有价值的信息，如果你有同款电脑并且屏幕有问题的不妨看看。 机械革命钛钽PLUS 花屏，黑屏，坏屏问题： 【铭达数码电子商行:机械革命蛟龙7 钛钽Plus 旷世 笔记本屏幕换屏教程。】 https://www.bilibili.com/video/BV1PN4y1W7jf/ 【机械革命 钛钽plus 刚过保 NE173QHM-NY2屏幕挂了 自己换屏】 https://www.bilibili.com/video/BV1mP4119768/ 原屏幕 面板 京东方液晶模组NE173QHM-NY2 面板型号 NE173QHM-NY2 详细信息见屏库网链接 https://www.panelook.cn/modeldetail_cn.php?id=49784 我在淘宝买了一块新的，A+品质，将近无暇的屏幕，我选择了NZ2这个型号 面板 京东方液晶模组NE173QHM-NZ2 面板型号 NE173QHM-NZ2 详细信息见屏库网链接 https://www.panelook.cn/modeldetail_cn.php?id=54632 屏幕到货，准备拆下旧的屏幕，建议参考上面第二个bilibili视频，记住要点 一定要先断电再拆屏幕（电池的排线也要断开，所以要拆后盖） 易拉胶一定要清除干净，这玩意还是挺粘的，不清除干净影响屏幕取下。如果易拉胶断头了，用薄的翘片或者不用的卡片（比如说过期了的理发店会员卡）借助吹风机从上往下“切断”易拉胶，这个时候如果能将易拉胶拉出来就更好，后面就小心“卷出来”易拉胶即可 换上新的屏幕先测试屏幕是否能点亮，可以再装回去 我拆下了的旧的显示屏 一次就成功点亮显示屏 旧的NY2屏幕 新的NZ2屏幕 换上了新的 NZ2 显示屏，但是开机后只能 60Hz 使用，切换到 240Hz 就闪屏。我在网上查询，都说是intel核显电压不足导致的，也可能就是核显问题，和供电电压无关。再问客服，客服给了我一个视频，让我从 bios 里切换到 dGPU only （也就是独显 only），默认是 hybrid 核显独显混合模式。实际上就是机械革命的电竞控制台独显直连的开关，我观察了开和关会让bios里变成混合模式/dGPU only，只不过有些人说在bios里修改会更稳定 那就切独显直连吧 但我切换到独显就无法开机，重启（或者开机）进入到输入密码的界面机器就强制关机了（键盘灯灭了），后面问客服，客服找到了技术，技术找我要电话，打电话给我，但他也并没有给我任何实质性的建议，或者操作方式，于是我就说算了吧，我就60Hz 用。。。 我在网上搜了一些资料 有的说需要重置 bios，我做了没有用 有的说需要关闭 windows 电源管理的 fast boot 快速启动，但我检查了我的 win11已经没有这个选项了 我都测试了，但没有成功。在我抱着试试的态度，将 Secure Boot 关掉，最后又因为 BitLocker 问题重新打开了 Secure Boot，最终保存 bios 设置重启电脑，居然就成功启动了！！！ 最后核显被成功屏蔽，资源管理器当中只显示了 GPU0 - nvidia rtx 3060 laptop gpu，并且在显示设置中将刷新率调到 240Hz 也正常运行，不会闪烁了，不会闪屏了，太棒了！ 并且这一个 display 也显示 connected to rtx 3060 所有测试完毕，使用3mm黑色双面胶粘贴在屏幕周围塑料边框上再将边框贴紧 将屏幕装好，再拆下D壳，将电池排线重新连接上，最后装好D壳，就完成了，完美搞定（实际上不是完美，在用纤维布擦拭屏幕时将呼吸灯的一颗灯珠碰掉了。。😭️ 不过也无伤大雅就是）

记录一次pve宿主机和上面的debian虚机无故down机事件
type: item
date: 2025-09-05T17:13:00+08:00
description: 我去年8月出去旅行，今年8月出去旅行，在外面访问家里 memos，都挂了，我每次都吐槽出远门家中网络必挂，-_-。一开始我一直认为是主路由网络挂了，以前我用的是野路子来的 OpenWrt 固件（比如各种高大全固件），但是今年我转战了 ImmortalWrt 官方构建的固件，这个稳定性很好建议使用这个。建议从他们的 firmware-selector 网站下载适合你的镜像 -> https://firmware-selector.immortalwrt.org/ 第一次down机买了个风扇给机械硬盘散热 最近发现可能不是这么回事，应该是我的 pve 宿主机和上面的 debian11 虚拟机的问题，这个问题从一次远程访问家中 pve 宿主机执行一些命令时候报错 Input/output error 开始。 我的 pve 宿主机上有两块磁盘，如下 NAME SIZE MODEL sda 3.6T ST4000VX000-2AG166 nvme0n1 238.5G HS-SSD-C2000Pro 256G 在宿主机上执行各种需要读写磁盘的命令都会报错 Input/output error 回家后发现主机温度很高，直接强制断电了，然后将外壳拆下，发现机械硬盘非常烫，我就赶紧拿起风扇对着吹。 大概吹了30多分钟，主机很凉快了，尝试再次开机，发现一切如常。支线：决定购买风扇增加散热 第二次down机发现已失效的nfs挂载 第三天发现memos又无法访问了，进 pve 终端查看虚机状态是 RUNNING，但是 ping 不通，最后只好执行 qm stop 100 && qm start 100 重启了一下虚机，也正常了。接着进入debian11 的终端立即检查，发现了关键错误 Read-only file system, rsyslogd: file '/var/log/syslog' write error - OS error: Read-only file system 从日志中的 Read-only file system 错误可以看出，你的系统根文件系统已被内核强制挂载为 只读模式 。这是Linux系统检测到严重磁盘错误时的保护机制，防止进一步数据损坏。以下是详细分析和解决方案： 关键日志解读 核心错误 ：rsyslogd: file '/var/log/syslog' write error - OS error: Read-only file system 含义 ：rsyslog（系统日志服务）尝试写入 /var/log/syslog 时失败，因为文件系统已处于只读状态。 还有一段核心错误 kernel: FS-Cache: Duplicate cookie detected kernel: FS-Cache: O-cookie c=00000000439c879b [p=000000000e48f285 fl=222 nc=0 na=1] kernel: FS-Cache: N-key=[16] '0400000002000000020008010a0a0a01' 这段日志帮我找到了磁盘挂载的问题。我查看 /etc/fstab 发现了4个无效挂载点(下图是我注释之后截的) 原来是我以前在软路由（10.10.10.1）上接了这4块硬盘，但是后来取下了这几块硬盘，然后这边没删除，给忘掉了。几年前就意识到要将家里各种设备的职责划分清楚，软路由就只专心做好路由，不搞下载和做种，所以当时就把这几块硬盘拔掉了，对应的 NFS 服务也就不存在了。所以现在这个小问题的解决办法就是删除这几行或者注释这几行。 pve宿主机 /etc/fstab 这个文件还硬编码写死了这几个挂载，导致拖慢系统，有时候甚至卡死了，于是我赶紧添加了注释，重启了pve，再次执行 journalctl -b -p 3 --no-pager 输出如下 -- Journal begins at Sun 2025-07-27 21:59:23 CST, ends at Fri 2025-09-05 22:04:09 CST. -- -- No entries -- 没有输出就是最好的状态，于是我以为这就解决问题了。 第三次down机安装intel-microcode后彻底解决 第四天发现又访问不了 memos 了。这一次一定要找到原因。在我大量的 google, bing, chatgpt, deepseek 之后，看到一些有用的信息，猜测有可能是内核版本 5.13.19，pve版本7.1-7，还有我的CPU Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz 之间的冲突。也看到了国内恩山论坛这个帖子 https://www.right.com…

给图床部署cdn腾讯云的edgeone并排查Cache-Control max-age 3600的问题
type: item
date: 2025-08-19T11:13:00+08:00
description: 正篇 最近发布了徒步反穿武功山，以及自驾皖浙赣的游记文章，点我直达 ，我分享到了 v2ex 以及 linux.do ，各路网友都说图床太慢了。由于原文图片数量的确较多，我的图床部署在家里，然后只有 VPS 的6Mbps小水管，在并发不大的时候阅读文章还行（图片加载的速度还OK，并且有配置懒加载，所以体验还行），但是昨天发了帖子之后有几波流量激增。于是我寻找办法： 准备使用活菩萨 cloudflare，但是要整体迁移域名解析到 cf，因为我这个域名有经过备案，并且数量众多，而且还要兼顾国内访问速率，我就放弃了 cloudflare 方案 准备在源图床那边创建新的存储策略，当前是存储在本地磁盘的，然后想想又要买对象存储，又放弃 最后发现了腾讯云的 edgeone，开通试试一个月只要4.8元，实付款4.7，最近微信支付很多借记卡、信用卡减免活动 最终我买了一个月的 edgeone，只花费4.7元~ 现在部署好了 cdn，访问速度大大增加。当前时间点 2025-08-19 10:30:42 edgeone 流量情况 我这篇文章不算是教程吧，只能是个人的心路历程，我也不想写保姆级教程，太费事了。在此就简单讲讲过程和原理。 首先购买了一个月的 edgeone 产品，需要绑定站点，首先绑定根域名，也就是 940304.xyz 然后经过认证 域名认证方式是：添加 TXT 类型记录，主机记录和对应的值都是 edgeone 给出的，我的域名托管在 dnspod，需要在 dnspod 那边改 也可以不认证根域名，每个二级域名都分别认证 通过CNAME 方式接入 CDN，需要先停止解析或删除之前的 image 主机名的 A记录（DNS A记录），然后添加 image 主机名的 CNAME 记录（因为同一个主机名A记录和 CNAME记录只能有一个条） 创建成功后就等待 edgeone 下发 cdn 配置，等待部署生效即可 我顺利的部署成功，也看到 edgeone 流量页面产生了非常多的数据，当前我博客中的多图文章访问体验肯定就好很多了。 但是后面我发现一个问题，就是图片资源访问后返回头当中的 Cache-Control 始终是 max-age=3600，这说明 cdn 边缘节点只会缓存这张图片一个小时，如果用户在一个小时之后访问同链接会无法击中缓存，导致cdn节点回源获取原始文件，这势必会增加很多源站的流量，我的公网VPS以及家里服务器的流量都会增大，设置CDN的效果就大为下降了，而且我这就是图床程序，资源是静态的，不需要长时间变动。一般情况下图片资源都会设置30天后过期，也就是 max-age=2592000(单位s)，于是我开启了排查。 在部署 edgeone 之前，我的图床架构是这样的 在部署 edgeone 之后，我的图床架构变成这样 在任意有网络机器执行 curl -I https://image.940304.xyz/i/2025/05/21/682dd7d3137c3.jpg 发现返回 Cache-Control: max-age=3600，我开启了漫长的排查，总结下来就是 1、在VPS上修改 nginx 配置，显式增加 Cache-Control 的返回头，设置成 public, max-age=2592000，但是无果 2、在以上基础上，区分单独的匹配图片的 location，因为之前是一个反向代理 location / 就能搞定 配置是这样的 location ~* \.(jpg|jpeg|png|gif|webp|ico|css|js|svg|woff2)$ { proxy_pass http://127.0.0.1:81; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $host; # 30天缓存（仅对静态资源） add_header Cache-Control "public, max-age=2592000, s-maxage=2592000"; # 跨域允许设置，允许所有跨域 add_header 'Access-Control-Allow-Origin' *; # 自定义 Debug 头部（仅用于测试） add_header HDKRESP "This-request-matched-jpg-location_test"; # 新增 # 跨域允许…

从高山草甸到徽派古村：武功山反穿与皖浙赣自驾行记
type: item
date: 2025-08-16T23:45:00+08:00
description: 前排提示：本文存在大量图片和少量视频，但均已压缩，请放心阅读 ^_^ 前言 最近几年的8月旅行我都写了游记，在此给个超链接 2022年：2022年打卡南京市区人防工程纳凉点 2023年：第一次4+2旅行，骑行皖南川藏线 + 再次出发，自驾徽州天路和黄山之行 2024年：2024年8月我的宜昌 - 重庆 - 川西小环线自驾旅行分享 时间又到了2025年8月，换我来享受一把假期，2号到10号，一共9天。 做攻略的时候看了很多，但最后都无法下定决心，这几天刚好非常热，想去高海拔地区避暑，同时不想报团游，最终还是觉得自驾游更有体验感。在bilibili看到这个视频，觉得很不错，这个博主分享的自驾线路以及推荐的地域非常客观合理。【8月全国自驾大盘点】 https://www.bilibili.com/video/BV1WTuzzWEZP/ 原本打算去玩个伊犁小环线，也打算去贵州西部来个小环线，还打算去云南西北部，走走国道G219，去年去过川西小环线，今年因为各种原因最后放弃了远行。后面就决定环江浙皖赣了，😄 皖浙赣也有一部分地区海拔1000+，晚上甚至可以露营。最后和我哥一拍即合，旅行走起。 本次旅行只进行了7个完整天，和我们的预期相符，花费也没有很多。先看看旅行路书总览图。 Day 1 - 8月2号 收拾好行李箱带上防潮垫、睡袋和登山杖，坐高铁去合肥。 收拾到下午3 4 点，我们才从合肥出发，一开始打算直接到萍乡，但是出发晚了，最后决定夜宿南昌，刚好都没有去过南昌，听说南昌的夜景也不错。 在路上的感觉真好，我喜欢这种轻松的自驾游 由于是从合肥到南昌，高速上会经过我们的老家潜山市，还在【王河服务区】停车休息了。看到这个服务区的一些设施，就感觉非常的local，很潜山。比如： 有一排水龙头的洗漱池，我们以前高中也是这样的，貌似潜山很多公共场所都有这样的设计 公共厕所，开水房，都有地方印记 晚上9点多到达南昌，看到八一广场摩肩接踵的人们惊呆了，昨天就是建军节，今晚继续热闹是吧。 找好了酒店，今晚就好好休息，明天再来逛逛南昌城。刚好明天是周日，不宜直接去武功山人挤人，挑个工作日再去正合适。 Day 2 - 8月3号 来了南昌必须要吃一吃江西美食。这个带辣椒的烤肠太香了，居然只要4块钱，也在洪都大拇指喝了奶茶，感觉也不错，比茶颜悦色便宜，个人感觉也更好喝。 打卡地点：万寿宫，大士院，滕王阁，八一广场，八一大桥。分享一些照片 超地道的南昌炒粉！ 这个拌面也很不错 苏超火起来之后，赣超，粤超也都搞起来了。赣超的热度还是不错的，比粤超强。 在八一大桥边 为了滕王阁这个机位走了好久，热的一批当时，但是效果并不是很满意，被小某书骗了。 晚上爬楼拍到了这张【滕王阁】绝景，有时候坚持等待会有收获。 但因为爬楼拍照和等待赣江对岸的建筑亮灯，就7点半之后才能出发前往萍乡了，今晚定了那边的民宿，明天将要徒步反穿武功山。这将对我是一个挑战。只是又要开夜车了... 夜里凌晨0点才到民宿，事先打电话让民宿老板将房卡放在桌上，写个我名字的纸条，在此感谢民宿老板，我们顺利到达也顺利入住，洗去风尘就入睡了。 Day 3 - 8月4号 我们昨晚将车辆停在反穿的终点，也就是定的这家民宿家。今早打车去龙王山。重装徒步，我们还带了帐篷和睡袋，打算今晚在武发客栈附近露营一晚上，目标地海拔1600，夜里应该很凉快。 武功山-发云界枫林山庄登山口 整装待发，踌躇满志（指出发时，小小的我不知道后面的艰辛万苦） 徒步一开始遇到的妹子们也是重装，厉害厉害 一家三口的重装，小孩哥也太强了吧😂 有一说一，爬到这个第一站的难度好大，我爬到这里时已累成狗，加上低血糖，有点体力不支。简直地狱般开局 后面很多个补给站都没有拍，因为身上都湿透了，加上半山腰有很多带水汽的云团，手机摄像头都雾蒙蒙的。我在后面的两个补给点斥巨资买了三瓶原味有糖的可口可乐，500ML的，在第一家老爷爷那买了两瓶（我担心后面价格会更高😂），15块一瓶。第二家是个小哥哥营业，13块一瓶还让我上了个厕所（不然两块钱一次）。 用沾满水雾的手机拍了这张照片 爬了两个多小时，感觉身体渐渐适应并且有力气了起来，而且也遇到了一些平缓的山路，不像一开始的一段路海拔爬升太多了。 爬过最抖的两个多小时路段，来到一片平地，此时云雾缭绕，我们身处云团间，伸手见不到太远，湿度爆表。 全国统一的我在xxx很想你 到了中午，我们补充了能量，顺便也给身上的背包减轻负重。然后我找到一个补给点，点了一份蛋炒饭，居然只要20元，天地良心啊，吃完蛋炒饭我能量满满，还直接铺上蛋巢防潮垫在老板家地上简单午休了会。休息完继续出发，迎接我的是喜人的美丽风景！ 下面这几张照片是拿出相机拍的了。不过此行相机拿出来的不多，实在是太累了，搞不动。 第一次爬到海拔1500左右的地方，遇到了风…

增程器就是充电宝？别被忽悠了
type: item
date: 2025-05-14T09:33:00+08:00
description: 如果你畅游社交网络的汽车区，经常有人分享“增程车的增程器就是个充电宝”这样的观点，更有甚者，觉得“1.0L, 1.5L 1.5T 都可以做这个充电宝”。这些排量+是否有涡轮增压的发动机都可以做增程器是不假，但很影响用车体验，并且和车的设计以及定位密切相关，如果是一辆通勤代步小mini车，整车不到4米长，高速需求少，那么增程是非常理想的方案。但是我看大部分买了某 6 7 8 9，以及另一个某8 9 车型的人，是经常跑高速的，这种如果不讨论燃油经济性，也会造成他们的电池很快跑完“可用”循环，并且长时间大功率放电会加速这些电池的衰减。 我从一个点切入，你就知道 1.5T 增程器用在“百万豪车”为何不妥了。 当电池电量 30% 时，三元锂电池整包的放电功率大概只有满电时的60%~70%，如果此时用户正在从【泸定县城】爬往【折多山垭口】，这个例子太具体了，我们换成高速上紧急加速场景。某增程车?6（?代表一个字符）欣旺达三元锂电池包 36.8度，我查到他峰值是8C的放电倍率（几乎只能维持10+s），但是高负载（能扛住长时间大功率需求）时放电倍率只有3C，满电时放电能力有294.4kW，那么30% SOC 时候放电功率只有 110.4kW，无法满足此时的功率需求。 还有一个重要的点，也许很多人知道但是忽略了，电池包同一时间只能进行充电/放电，不可能既在放电又能充电的。 所以上面的场景下，很大可能是发动机+电池共同出力满足电机需求的。发动机 -> 发电机 -> 驱动电机，如果此部分功率不够，整车系统还会继续从电池中取功率喂给驱动电机。 这部分的能量传输路径是：发动机 - 发电机 - 交流电转直流电（AC to DC）- DCDC控制器 - 直流电转交流电（DC to AC）- 驱动电机 - 减速器/差速器 - 车轮。 能量转换图 发动机 → 发电机（AC） → 整流器（AC/DC） → 高压直流母线 → 逆变器（DC/AC）→ 驱动电机 ↓ DCDC（DC/DC）→ 12V系统 所以增程车的增程器只是个充电宝吗？不是，某种意义上他也会参与“直驱”，但是他“直驱”的形式是通过曲轴带动发电机发的电驱动车轮前进。 我们在讨论直驱时，到底是在讨论什么？插混直驱就是发动机曲轴的力通过一些机构直接作用在车轮上，而不经过上面那一大串路径了。城区低速场景，功率需求比较低，大部分时间功率需求都在100kW以内，纯靠电池就能提供，这时候插混和增程是一样的，都是在合适的时间启动发动机专门发电，然后部分功率用于驱动，剩余功率充进电池。

浦口龙虎巷扫街，记录人间真实
type: item
date: 2025-05-12T22:28:00+08:00
description: 龙虎巷的高大梧桐树今年被政府砍断了，原本颇有老街风貌的街区瞬间失去了一些色彩，但这里依然还有很多魅力，昨天带上索尼 FE 35mm F1.8 去拍了几张照片，特此分享。 还遇到一个大爷，骑着电瓶车就来我跟前，“小伙子来摄影呀”，还颇健谈，和我讲以前浦镇的神话，甚至邀请我去他家喝酒…… hhhh

博客图片压缩方案更新｜AVIF｜WebP｜MozJPEG｜标准JPEG
type: item
date: 2025-05-12T15:46:00+08:00
description: 今天看B站动态当中的配图文件格式是 AVIF，瞬间起了兴趣。 然后才发现我的博客这么多图片我一直还在使用 MozJPEG 格式压缩的，虽然 MozJPEG 压缩率已经很高了，但看到更先进的算法不由得还是心动了，于是决定进行一些研究和寻求一些改变。 Squoosh 是 Google chrome labs 推出的，他支持压缩成 AVIF, MozJPEG, BrowserJPEG（就是标准JPEG）, WebP 等格式，我一直用他压缩图片。他是开源的，源码在 https://github.com/GoogleChromeLabs/squoosh 支持这么多压缩算法 Squoosh各种压缩算法对比表 算法名称 核心技术 优势场景 劣势 兼容性 AVIF AV1视频编码 超高压缩率（50%+），支持HDR/广色域 编码速度慢，旧浏览器不支持 需现代浏览器 Browser JPEG 传统JPEG 快速压缩，广泛兼容 压缩率/画质均低于优化算法 全平台兼容 JPEG XL (beta) 新一代JPEG 渐进加载，兼容传统JPEG，超高画质保留 尚处beta阶段，生态未普及 实验性支持 MozJPEG 优化版JPEG 比传统JPEG节省20%-30%体积，兼容性好 无法突破JPEG格式限制 全平台兼容 WebP Google VP8 比JPEG小30%+，支持透明通道 部分旧设备不支持，不支持渐进加载 主流浏览器支持 WebP v2 (unstable) 升级版VP8 比WebP体积更小 不稳定，可能产生画质异常 实验性支持 （注：PNG相关算法未列入主推荐，因PNG格式不适合照片压缩） 我的目标是占用存储空间小（用户访问文章图片加载也会更快），画质能接受不能太差，所以最好的方案是 AVIF，但是兼容性差，图床支持也不行。 最佳选择是这样的 优先级排序：AVIF > WebP > MozJPEG 1️⃣ 首选：AVIF 优势：在 Squoosh 实测中，AVIF 能以 1/3 原图体积（约70%压缩率）保持肉眼难以察觉的画质损失，支持更广色域。 场景：适用于现代浏览器环境（Chrome 85+/Edge 89+），适合博客/电商等需要极致加载速度的网站。 操作建议：压缩时设置 质量等级 65-75，开启 色域保留 选项。 2️⃣ 次选：WebP 优势：体积比原JPEG减少 30-50%，兼容主流浏览器（Chrome/Firefox/Edge），支持透明度。 场景：需要兼顾兼容性与压缩率的场景，如移动端APP、社交媒体图片。 操作建议：设置 质量等级 75-85，勾选 自动滤镜优化。 3️⃣ 保守选择：MozJPEG 优势：完全兼容所有设备，通过智能量化表优化，比原JPEG节省 20-30% 体积。 场景：必须保持.jpg格式的场景（如老CMS系统），或目标用户使用旧设备（IE/老旧安卓机）。 操作建议：设置 质量等级 75-80，开启 渐进加载 提升感知速度。 下面实测我拍的一张南京长江大桥图片，分别使用 AVIF, MozJPEG, WebP 压缩，每种压缩算法均使用 Squoosh 默认压缩选项，来比比看吧 原图 jpg，大小 8.5MB MozJPEG WebP AVIF 可以看出，MozJPEG -> WebP -> AVIF 压缩率逐步提升，文件体积不断减小，我看了一下画质均在可接受范围内，其中 WebP 我勾选了【Auto adjust filter strength 自动调整滤镜增强】（不会影响压缩率和文件体积，只会影响画质），一个表格来表达 算法名称 压缩率 压缩后文件体积 MozJPEG 88% 1.09MB WebP 91% 812KB AVIF 95% 419KB 从表格可以看出 AVIF 压缩率和新文件的文件体积都遥遥领先，这正是未来趋势。不过使用 AVIF 压缩时间很久，电脑风扇也会呼呼转，这也是代价。 我使用的图床是 Lsky Pro，不支持 avif，开源版本目前也不会迭代了，更不会增加新需求。综上，我今后将使用 WebP 作为图床图片的格式，虽然比 MozJPEG 也没有强多少，但是总归是要更好的。

Windows 电脑使用 Obs Studio 录制各个网站视频/桌面画面教程
type: item
date: 2025-04-25T17:18:00+08:00
description: 我分享这个 flow 是因为我有分享视频中片段的需求，但是又不想用相机拍摄，相机拍摄效果可能也不好。下载下来再裁剪又太麻烦。尤其是我喜欢看车祸警示录，有时候看到某些事故非常搞笑，我就用这个手段录制下来，视频可能就10s，30s，然后再微信分享，就很 nice 了。如果是分享10min的完整视频那种，就不如直接贴链接，或者直接下载下来再分享，不需要使用本文方案进行录制。 前言 你是否会因为难以下载 YouTube, X(Twitter), 小红书, Instagram, 微博 之类的网站上的视频而发愁呢……虽然下载这些网站的视频大多都有在线工具或者命令行工具，可以在 GitHub 寻找。 但是目前经过我的日常使用，小红书和微博上的视频资源不是很轻松就能下载下来，或者下载用时很久，还可能下载下来文件太大（比如下载时无法执行码率和分辨率），不利于再次分享。 我为了解决这个问题，一开始使用了 NVIDIA Geforce Experience，但是这个只能录制屏幕的完整内容，如果想要录制屏幕当中的某一块区域，英伟达这个软件就不行了。 于是转而使用 Obs Studio。下面这段介绍来自 DeepSeek V3 OBS Studio（Open Broadcaster Software）是一款免费开源的跨平台直播和录屏软件，广泛用于游戏直播、教学演示、视频创作等场景。以下是其核心特点： 1. 核心功能 多场景切换：可创建多个场景（如游戏界面、摄像头画面、PPT等），直播时实时切换。 来源组合：支持添加窗口捕获、摄像头、文字、图片、浏览器、音频等元素，自由布局。 高性能录制：支持高帧率（60fps+）、高分辨率（4K）录制，输出为MP4、MKV等格式。 直播推流：一键推流到Twitch、YouTube、B站等平台，支持RTMP协议。 2. 技术优势 低延迟编码：内置x264、NVENC（NVIDIA显卡）、AMF（AMD显卡）等硬件加速编码器。 音频控制：多轨道音频混合，支持降噪、增益等滤镜。 插件扩展：通过插件支持虚拟摄像头、字幕、特效等扩展功能。 3. 适用场景 游戏直播：捕获游戏画面+摄像头叠加，实时互动。 网课/会议：录制屏幕+PPT演示，或虚拟摄像头接入Zoom/Teams。 视频创作：录制教程、剪辑素材，支持后期音频分离编辑。 4. 跨平台支持 支持Windows、macOS、Linux系统，界面简洁但需一定学习成本。 5. 注意事项 硬件要求：高清直播需中高端CPU/显卡，建议提前测试性能。 学习曲线：高级功能（如音频路由、动态滤镜）需查阅教程。 官网下载：OBS Project 社区活跃，遇到问题可通过论坛或GitHub快速解决。适合追求高自由度、零成本的用户。 我在使用 Windows 11 电脑。安装好 Obs Studio 之后，打开软件，进行初始化配置，我不直播，所以只进行了 recording 录制相关的初始化，最后 apply settings，应用设置。 添加源。我拿录制B站车祸警示录的视频举例，使用 edge 浏览器播放B站视频，那么来源选择【窗口采集】，选中正在运行的 edge 那个窗口，标题前缀是 [msedge.exe]， 如果不想录入当前电脑麦克风的声音，请将 Mic 给静音。 此时会录制整个窗口的画面，如果想录制视频播放区域，需要添加一个裁剪/填充的【滤镜】，如下图，设置好距离左，顶部，右，底部的像素数量关闭即可。 在开始录制前确保输出的视频画面充满整个画布，勾选使用此源的尺寸作为输出分辨率 （重要重要！否则输出的视频可能有很多“留黑”空白区域） 最后再点击【开始录制】，同时播放 edge 浏览器窗口的视频，在视频结束时（或者你想截取的视频片段刚好结束）点击【停止录制】。 最终录制视频呈现的质量，设置项在 【设置】->【输出】->【录制】->【录像质量，录像格式，视频编码器，音频编码器，音轨】等配置。 建议录像格式使用MPEG-4，方便传播，比如微信就可以直接预览 mp4 视频。

为typecho博客添加latex支持
type: item
date: 2025-04-25T13:40:00+08:00
description: 使用了这个插件： https://github.com/zyuzhi/MarkdownKatex-typecho ，下载了 v1.0.1，但是点击创建文章之后无法返回所有文章页面。另外博客首页也无法加载，禁用插件即恢复正常。懒的去追究原因了，索性不用插件改用其他方法。 我家里的一台机器也部署了 typecho，同样都是 docker compose 部署的，和当前 typecho 实例的区别大概就是 v1.2.0 vs v1.2.1 。家里机器上的 typecho 是 1.2.0，当前实例是 1.2.1，有可能是版本升级导致的原有插件失效，因为上述插件 GitHub 源代码是2018年左右最终打包到 release 发行的。 在 typecho v1.2.1 实例上测试如下方法可以为 typecho 博客添加 latex 支持。 方法参考： https://www.xrgzs.top/posts/typecho-use-mathjax-add-latex-support 修改当前主题的 header.php 将以下代码添加到 header.php 的适当位置。我这个主题这个文件在 components/header.php。 注意：footer.php 中就不需要重复引用这个 script 了。 mardown + latex 测试 牛顿第二定律 物体所受合外力 $\mathbf{F}$ 与其加速度 $\mathbf{a}$ 满足： $$ \mathbf{F} = m\mathbf{a} = \frac{d\mathbf{p}}{dt} $$ 其中： $m$ 为物体质量（单位：$\mathrm{kg}$） $\mathbf{p} = m\mathbf{v}$ 为动量（单位：$\mathrm{kg \cdot m/s}$） $t$ 为时间（单位：$\mathrm{s}$） 万有引力公式 两个质点间的引力大小： $$ F = G\frac{m_1 m_2}{r^2} $$ 式中普适常量： $G \approx 6.674 \times 10^{-11}\, \mathrm{m^3 \cdot kg^{-1} \cdot s^{-2}}$

新能源汽车之纯电车使用交流慢充和直流快充的充电损耗对比
type: item
date: 2025-04-25T13:15:11+08:00
description: 以下是我和DeepSeek R1的对话 USER 新能源汽车使用7kW 交流慢充和外面的直流快充，哪个充电时损耗更高？7kW 交流慢充的电流大概30A，44度电池大概需要7个小时；使用外面直流快充桩，假如功率是70kW，充满需要1小时，但是充电电流最大180A左右。请计算一下哪种充电方式电损耗更多？ ASSISTANT 嗯，用户问的是新能源汽车用7kW的交流慢充和外面的直流快充，哪个充电时的损耗更高。需要比较两种充电方式的电损耗。首先，我得理清楚问题的各个参数和可能的损耗来源。 用户给出的数据是，7kW慢充电流约30A，44度电池需要7小时充满。而直流快充功率70kW，充满需要1小时，电流最大180A。用户希望计算哪种方式损耗更多。 首先，我需要明确充电损耗主要包括哪些部分。通常来说，充电损耗可能来自几个方面：充电桩本身的效率、线缆的电阻损耗、电池在充电过程中的热损耗，以及可能的转换损耗（比如交流转直流时的损耗）。 但这里可能需要简化问题，因为用户可能只关注其中一部分损耗，比如线损或者充电效率差异。但用户没有明确说明，可能需要自己做一些合理的假设。 首先，对于交流慢充，7kW的功率，电流30A，电压应该是220V左右（因为功率=电压×电流，7kW=7000W，7000/220≈31.8A，接近30A，可能实际电压更高或者电流略高）。而直流快充的话，70kW功率，电流180A，那电压大概是70000/180≈388.9V，这符合一般直流快充的高电压情况。 接下来，考虑线损。线损主要和电流的平方成正比，和电阻成正比（P=I²R）。所以，线缆的电阻会影响损耗。但需要知道线缆的电阻值，或者比较两种情况下电流的差异导致的损耗差异。 不过，这里可能需要区分交流慢充和直流快充的充电过程。交流慢充的情况下，车载充电机（OBC）将交流转换为直流给电池充电，而直流快充是直接由充电桩提供直流电，绕过了车载充电机。因此，两者的损耗可能不同，交流慢充会有OBC的转换效率问题，而直流快充可能有充电桩内部的转换效率以及线损。 假设线缆的电阻相同的话，那么线损取决于电流的平方乘以电阻。但实际情况中，直流快充的线缆可能更粗，电阻更小，但电流更高。不过用户可能没有给出线缆的具体参数，可能需要假设两种情况下的线缆电阻，或者比较相对损耗。 或者，用户可能只是希望比较两种情况下电流不同导致的线损差异，假设其他条件相同。 不过可能更全面的考虑是，整个充电过程的效率，包括充电桩的效率、线损、车载充电机或电池管理系统的效率等。 例如，对于交流慢充：电网的电能先经过充电桩（可能效率接近100%，因为交流传输），然后到车载充电机，OBC将交流转换为直流，并调整电压到电池需要的水平，这个过程的效率通常在85%-95%之间，比如假设是90%。然后，线损部分，电流30A，线缆电阻假设为0.1Ω（随便举个例子），那么线损是I²R=30²×0.1=90W，持续7小时，总损耗是90W×7h=0.63kWh。同时，OBC的效率损失是，输入到OBC的电能是7kW×7h=49kWh，输出到电池的是44kWh（因为44度电池），所以OBC的效率是44/(49)≈89.8%，接近90%。这里的线损可能已经包含在OBC的效率中，或者需要额外计算？ 而直流快充的情况，充电桩本身将交流转换为直流，效率可能在90%左右，然后线损部分，电流180A，假设线缆电阻更小，比如0.02Ω（因为快充线缆更粗），那么线损是180²×0.02=648W，持续1小时，总损耗0.648kWh。同时，充电桩的效率如果是90%，那么输入到充电桩的电能是70kW×1h=70kWh，输出到车的直流电是70kWh×90%=63kWh，但实际充进电池的是44kWh（因为电池容量44度），所以这里可能还有其他损耗，比如电池充电时的效率，或者BMS的管理损耗，可能这部分效率假设为95%，那么从63kWh到电池的44kWh，可能需要计算是否合理？其实这里可能需要更准确的数据，但用户可能只是希望比较两种方式的总体损耗。 不过可能用户的问题更简单，即比较两种充电方式的总损耗，而损耗主要来自电流在传输过程中的线损和转换效率。因此，可能需要分别计算两种方式的总输入电能和实际充入电池的电能，差值就是损耗。 对于慢充：44度电池需要7小时，充电功率7kW，所以输入的电能是7kW×7h=49kWh，而充入电池的是44kWh，所以总损耗是49-44=5kWh。这部分损耗包括线损和OBC的转换损耗。 对于快充：70kW充1小时，输入电能为70kWh，而充入电池44kWh，所以损耗是70-44=26kWh？这显然太大，可能哪里有问题。因为实际上快充的充电时间可能不是一直保持70kW，特别是当电池接近充满时，充电功率会下降，所以用户说的“充满需要1小时”可能是指从…