本文记录给我的机械革命钛钽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机事件
我去年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.cn/forum/thread-8266555-1-1.html [虚拟机相关] 记录对于说N5105在PVE不稳定无故死机的一种解决方法 最后我增加了 non-free 的四个源之后，试图安装 intel-microcode，期待解决问题。 新的源文件/etc/apt/sources.list内容 # 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释 deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye main contrib deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye main contrib non-free deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-updates main contrib deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-updates main contrib non-free deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-backports main contrib deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-backports main contrib non-free # 以下安全更新软件源包含了官方源与镜像站配置，如有需要可自行修改注释切换 deb https://security.debian.org/debian-security bullseye-security main contrib deb https://security.debian.org/debian-security bullseye-security main contrib non-free 执行 apt update 之后执行 apt-get install intel-microcode，成功安装 intel-microcode 软件包 一段和chatgpt的对话，它照着日志讲出了核心原因 目前接着观望pve宿主机和debian11虚机的运行情况。 后续更新 2025年09月15日上午更新，稳定运行，10.10.10.5 是虚拟机 IP，宿主机本身的IP是 10.10.10.3，虚机没断过网络，各种服务也没有 down 过。基本上可以判断出之前就是因为 intel 微码没有安装导致的虚拟机 down…… 不过这个机器组装以及系统安装是在 2021 年，怎么现在才出现这样的问题呢……有点不解 # uptime 08:54:49 up 8 days, 19:06, 1 user, load average: 0.02, 0.03, 0.05 # ping -c 4 10.10.10.5 PING 10.10.10.5 (10.10.10.5) 56(84) bytes of data. 64 bytes from 10.10.10.5: icmp_seq=1 ttl=64 time=0.170 ms 64 bytes from 10.10.10.5: icmp_seq=2 ttl=64 time=0.198 ms 64 bytes from 10.10.10.5: icmp_seq=3 ttl=64 time=0.215 ms 64 bytes from 10.10.10.5: icmp_seq=4 ttl=64 time=0.214 ms --- 10.10.10.5 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3074ms rtt min/avg/max/mdev = 0.170/0.199/0.215/0.018 ms
给图床部署cdn腾讯云的edgeone并排查Cache-Control max-age 3600的问题
正篇 最近发布了徒步反穿武功山，以及自驾皖浙赣的游记文章，点我直达 ，我分享到了 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"; # 新增 # 跨域允许设置结束 # 防盗链设置，因为上述跨域是允许所有的，这里就要设置防盗链从而进行域名的白名单设置 valid_referers none blocked 940304.xyz *.940304.xyz hellodk.cn *.hellodk.cn hellodk.com *.hellodk.com 10.10.10.5; #nginx不允许嵌套if语句，这个很关键，否则nginx -t 会测试失败，无法reload或者start nginx服务 set $block_access 0; # 如果 referer 无效 if ($invalid_referer) { set $block_access 1; } # 根据之前的判断结果决定是否拦截 if ($block_access) { rewrite ^/ https://i.imgur.com/CB4Fseq.jpeg; } } 这样的确能增加Cache-Control 的返回头，但是edgeone 那边始终没有生效。我还去lsky pro 图床程序的源 apache2 服务端添加了 Cache-Control 头，因为根据 edgeone 的规则，会先读源站的缓存相关的返回头（Cache-Control:s-maxage, Cache-Control:max-age, Expires），如果有会优先遵循源站的配置 edgeone 的文档：https://cloud.tencent.com/document/product/1552/87651 edgeone默认缓存规则 默认缓存规则文字说明 3、发现修改vps nginx配置无果，我进入了 lsky pro 容器，做了以下操作 # Apache 需要启用 mod_headers 才能使用 Header set 指令，启用这个模块 a2enmod headers # 修改生效配置文件 `/etc/apache2/sites-enabled/000-default.conf` 可以通过命令 `apache2ctl -S` 寻找生效的虚拟主机所在文件 # 并增加如下配置 <LocationMatch "^/i/.*\.(jpg|jpeg|png|gif|webp|ico|bmp)$"> Header set Cache-Control "public, max-age=2592000" </LocationMatch> # 重启apache2服务 service apache2 restart 现在图床源站点会给静态图片资源返回 Cache-Control 了，在图床容器中执行 curl -I http://localhost/i/2025/05/21/682dd7d3137c3.jpg 有如下返回 HTTP/1.1 200 OK Date: Tue, 19 Aug 2025 03:11:18 GMT Server: Apache/2.4.53 (Debian) Last-Modified: Wed, 21 May 2025 13:40:35 GMT ETag: "ef67-635a58279843c" Accept-Ranges: bytes Content-Length: 61287 Cache-Control: public, max-age=2592000 Content-Type: image/jpeg 在 edgeone 管理页面清除了这个URL https://image.940304.xyz/i/2025/05/21/682dd7d3137c3.jpg 的缓存，从 EO-Cache-Status MISS 到 HIT（也就是第一次请求未击中缓存cdn节点回源了，到第二次击中了缓存），返回的 max-age 仍然是 3600 4、开始排查 edgeone 这边，终于找到了原因所在！ 需要在这里点击站点加速，我以为默认的全局配置就是对的，因为设置的是遵循源站的 Cache-Control，所以一直没细看 这里全局配置是正确的，没毛病，但是右侧还有一个规则引擎默认是打开的（但是默认没有任何配置，尼玛坑死我），并且优先级更高。 规则引擎默认打开并且默认无配置坑我导致max-age一直是3600！！！（欲哭无泪 最后我因为不需要个性的规则引擎配置，我就将这边关掉了，直接使用全局配置，遵循源站的 Cache-Control 即可。 最终执行 curl -I https://image.940304.xyz/i/2025/05/21/682dd7d3137c3.jpg 返回了 Cache-Control: public, max-age=2592000 最终解决，这样可以减少 cdn 回源的频率，需求满足！ ok，如果你有任何疑问，欢迎留言与我讨论。 番外篇 edgeone国际版测速分享到X或者Facebook得FreePlan，网站 https://edgeone.ai 甚至分享到X+分享到Facebook可得两份FreePlan 我等当前买的国内版失效之前的几天就切换到国际版。但是需要注意的是，腾讯云的一份身份认证只能实名制一个腾讯云账号，edgeone国际版要想使用中国大陆节点需要实名认证的账号才行。我的身份已经实名了国内版的了，后面大概就选择国际节点 国内版edgeone产品，4.7元买的一个月
从高山草甸到徽派古村：武功山反穿与皖浙赣自驾行记
前排提示：本文存在大量图片和少量视频，但均已压缩，请放心阅读 ^_^ 前言 最近几年的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左右的地方，遇到了风雨，我们赶紧将携带的雨衣穿上。 您的浏览器不支持HTML5视频 徒步反穿武功山遇到短时雷阵雨 随后就是翻越一座一座的山，常言道望山跑死马，这对于渺小的人类来说一样，没想到这片山体能绵延不断如此之长。在绝望坡前我是真的蛮绝望的 您的浏览器不支持HTML5视频 攀爬绝望坡上的大石头路段，前面的岩石路段没有拍 您的浏览器不支持HTML5视频 爬上绝望坡遇到的一段平缓路 绝望坡岩石攀爬 随后找到了露营地，天也渐黑，我们就露营扎寨了。今天的里程只有13公里但是海拔总爬升有1700米 天黑了深山里仍然有不断的徒步人，我没想到的是，这状态一直持续到第二天早上，也就是说夜里0点有人深夜爬山，夜里2点还有人深夜爬山，夜里3点都有小队伍从我们的帐篷前走过，还讨论着夜空的星星，以及吊马桩（也有可能是草甸星空）那边的灯火通明。 Day 4 - 8月5号 第二天起床后的风景，今天早起看到了一般的日出 收拾好之后我们便出发。今天遇到蛮多同行玻璃栈道的人，大家都是反穿徒步的勇士，我们在金顶下的广场分别。他们登顶去了，而我，因为“烧裆”实在难受就坐中庵索道下山了 从玻璃栈道上回望，这里已经是景区路段，设施很不错，风景也很好，海拔相对高度达到了1000米左右 从前往金顶的广场下撤到中庵索道站还要走一个多小时，尽管是全程下山。看到很多挑物资上山的挑山工，是真的强也真的辛苦。 坐索道排队良久，下山后打车良久，才等到一个本地司机，经过他口中才知道当地村民设置了多个栏杆，阻止非官方车辆进出，只允许景区大巴和当地村民车辆通行，（可恶啊，但是赚钱） 下午在村子里吃到了一顿美美的饭，江西菜似乎毫不吝啬添加辣椒，或者泡椒之类的~ 出发前往景德镇市。 Day 5 - 8月6号 在景德镇留下的最深印象有几个： 当地的交通简直一笔掉草，骑电瓶车的都很无敌，随随便便占用最左侧的机动车道，在景德镇开车得慢点注意别撞了行人和骑电瓶车的 吃到了更便宜且更好吃的南昌拌面，4块钱一份早餐吃得饱饱的 游玩景德镇最好的方式是租一辆电瓶车，本着打不过就加入的心态我也租了，一天30元，能跑30+公里 除非提前一周就预约否则需要排队N个小时才能进的景德镇中国陶瓷博物馆，我也去了，感觉排的队是值的 网络流量让这个无语佛（无语菩萨？无语披萨，哈哈哈）爆火，它建于民国年间，正式名称是沉思罗汉。为了看它还得单独排个长长长长的队伍 很可爱很好看的陶瓷制品 我买了这个杯子，手柄既可以用作手柄，也能当作吸管，摆在桌上很好看，杯子容积也刚好，喝水都赏心悦目 陶溪川文创街区没啥好玩的，东西贵，各种店有些脱离群众了。但是这张照片我还挺喜欢 晚上吃好饭看到一个工人大叔在一个牛骨汤店点了一份普通的炒饭 晚上吃饱喝足出发黄山祁门县，因为路线选取失误，还走到了“塌方治理，车辆绕行”路段，幸好绕行路段不长，路况也不是完全不能走，最终又是在0点左右到达酒店。 Day 6 - 8月7号 在祁门县，又回到了我大安徽，小县城的面貌让我格外亲切，吃了一顿极其有性价比的早餐，还吃到了2块钱一份的炒面，以前初中上学的时候买早餐还能买3毛钱、7毛钱、1块钱的炒面。 没想到昨天预订的酒店就在华东蛇伤救治基地隔壁，而且昨晚前台引导我们停车也是停在了他们的院子里 祁门有两大特色，一是红茶，二是蛇伤救治基地。 祁门红茶 ：世界三大高香红茶之一，色泽乌润，香气独特似花似蜜，被誉为"红茶皇后"，祁门县核心产区所产尤为珍贵。 祁门蛇伤研究所 ：中国首个专业蛇伤救治机构，创立于1965年，以中西医结合疗法闻名，救治毒蛇咬伤水平全国领先，兼具科研与医疗功能。 准备出发去祁门统坑玩水，但是发现轮胎又报故障，胎压又回落到1bar左右。去检查发现确实扎了胎，只好等待修复。 旅行就是这样说不好说不准，刚好巧合的是，昨晚的酒店隔壁也是补胎店 -_- 补胎ing 我们到了统坑这边村庄门口，风景绝美。这个村名字叫湘东村，这里是牯牛降景区腹地，但还没有到开发的景区附近 道路的尽头还有这样的人家，其实和我们安庆山区的农村很像 统坑这边的绝美玻璃水。因为这里交通不便，海拔地势高，周围全是大山，所以这里的山谷里流淌的山泉非常非常清澈干净 非常美的水潭子，但因为今天下雨，并且温度不高，都没有往上下游探索更多更美的水潭 遇到一位80岁老奶奶，她说这里非常好，一辈子没生过病。我看她还真的健谈，另外手脚和精神都很不错，我说给她拍张照片留恋，她还主动将手中的矿泉水和雨伞放在身后的三轮车上站好身姿配合我的拍摄 虽然下了雨，但我依然游泳了，不然带的装备都白带了，俗话说来都来了。并且露营了，吃饭了，还带了西瓜、鸭货、罐装可乐雪碧芬达。注意：户外游玩请一定带走随身垃圾！ 然后还进行了小溪垂钓，钓到了非常多的石斑，这里环境的天然让我们惊呼，真的有这么好的水域！ 出发前往浙江临安太子尖驿站。240公里左右，3个多小时即到。晚上到达太子尖驿站，这里海拔1350左右，没想到居然有这么多人露营 今晚因为车辆就在帐篷旁边，可以换一个更大的帐篷了，相信可以睡得更好。 Day 7 - 8月8号 今天的行程就很简单，开车一路逛，看遍沿途风景。今天的大部分照片都是相机拍的，一起来欣赏沿途风景吧~ 早上在太子尖驿站向下眺望 临安华光潭村 青山绿水，这里实际上我23年12月来过，当时就没有这么好看，毕竟当时是冬季 皖浙天路——安徽和浙江的交界处，牌坊修的不错呐 这一幕总让我想起深山禅院，黑神话悟空之类的概念，看起来就很幽深静谧，宁静美好 古韵悠扬，徽州古村落的经典标志，安徽省三级古树——枫杨 到达了皖浙天路的最高处——饭甑尖 这里的风景令我惊异，比起上次去的徽州天路，这里更加险峻，山体很像天柱山的花岗岩 今天烈日当下，但有蓝天白云，这些照片回头望真的很美，当时晒了点也无妨了 皖浙天路笔架峰 中午在绩溪县家朋乡炒了几个农家菜，吃得很满足。我们询问了周围游客和老板，哪里可以去游泳，哈哈，最终经过这个地方，梯田美景，美不胜收，不虚此行 对面的山，形似“山”字，形象至极 下午我们从宣城绩溪县驾车来到黄山徽州区西溪南古村落，听说今晚这里有鱼灯表演，没看过，自然很吸引我 古村落里也有很多人溯溪 一群嗷嗷待哺的小猫 古徽州的古村落，古村落房子里的细节，有大堂，有牌匾，有壁画，有圆桌，因为现代社会也有了空调，相得益彰 西溪南的游船，颇有皖南风味 夜幕降临，看到有人在售卖鱼灯了 表演开始，成群结队的一行人需要从起点走到终点，我第一次看到这样的文化，真的仿佛回到了从前，社会生产力低下，人们祈福风调雨顺，国泰民安的淳朴向往 此时还有舞蹈表演，围观的人群很多 终点处放起了烟花~ 居然如此浪漫，我赶紧调整了相机的模式，尽量用S挡多捕捉几张美丽的焰火 看完西溪南的鱼灯表演，我们准备回到南京了，这次旅行将要画上终点，累也是真的累，幸好我们有两个人轮流开车，可以间歇性休息。 结语 行笔至此，已经花了超过6个小时，回望这次旅行，没有去往远方，但就在皖浙赣，也有非常不错的风景和人文，最初的想法是去避暑，但我们也去了高海拔地区露营，完美实现了心中所念。如果你也有想法出门转转，记得实施你的方案，远方的公路，远方的山水，就在那里。 感谢阅读，有任何想要交流的，欢迎评论区留言。
如果你畅游社交网络的汽车区，经常有人分享“增程车的增程器就是个充电宝”这样的观点，更有甚者，觉得“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以内，纯靠电池就能提供，这时候插混和增程是一样的，都是在合适的时间启动发动机专门发电，然后部分功率用于驱动，剩余功率充进电池。
龙虎巷的高大梧桐树今年被政府砍断了，原本颇有老街风貌的街区瞬间失去了一些色彩，但这里依然还有很多魅力，昨天带上索尼 FE 35mm F1.8 去拍了几张照片，特此分享。 还遇到一个大爷，骑着电瓶车就来我跟前，“小伙子来摄影呀”，还颇健谈，和我讲以前浦镇的神话，甚至邀请我去他家喝酒…… hhhh
今天看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 也没有强多少，但是总归是要更好的。
我分享这个 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 视频。
使用了这个插件： 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}}$
新能源汽车之纯电车使用交流慢充和直流快充的充电损耗对比
以下是我和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小时”可能是指从某个低电量到满，但实际平均功率可能不是70kW整个小时。但用户给出的数据是假设70kW持续1小时，所以输入70kWh，但电池只有44kWh，显然不可能，这显然不合理。这说明用户的数据可能有问题，或者需要更仔细的分析。 可能用户提供的例子中，快充的70kW功率下，充满44度电池需要的时间应该是44kWh /70kW≈0.628小时，即约37.7分钟，而不是1小时。用户可能在这里有错误，或者需要重新审视数据。或者，可能用户的意思是快充的功率在开始阶段可以达到70kW，但随着电池电量增加，功率会下降，所以总时间需要1小时。但这样的话，实际输入的电能应该还是44kWh加上损耗，所以总输入可能接近44kWh / 效率。例如，如果充电桩和线路效率是90%，那么输入电能为44 /0.9≈48.89kWh，那么充电时间就是48.89kWh /70kW≈0.7小时，约42分钟，但用户说需要1小时，可能效率更低或者有其他因素。 这里可能存在数据矛盾，需要用户澄清，但可能用户是假设理想情况下，快充以70kW充1小时，总输入70kWh，但电池只有44kWh，这显然不可能，所以可能是例子中的数值有问题。或者，可能用户提到的“44度电池”需要充的电量不是从0到100%，而是部分充电？例如，如果电池剩余20%，需要充80%的电量，即35.2kWh，那么快充70kW的话，时间约35.2/70≈0.5小时，约30分钟。但用户说需要1小时，可能例子中的数值有误。 或者，可能用户混淆了电池容量和充电量。例如，电池是44度，但使用快充时，充电量可能更大，因为存在损耗。例如，假设快充的总输入电能为70kW×1h=70kWh，其中充入电池44kWh，那么损耗为26kWh，显然这效率太低了，只有62.8%，这显然不合理。因此，可能用户的数据有误，或者需要重新考虑。 可能正确的数据应该是，快充的充电时间是根据电池容量和充电功率计算的，例如44kWh /70kW≈0.628小时，即约37分钟，而用户可能提到的1小时是包括其他因素，例如充电速度下降或者不同的SOC区间。但无论如何，用户给出的数据可能存在矛盾，需要进一步确认。 不过，回到问题本身，用户可能希望比较两种充电方式的损耗，基于他们提供的参数，即使数据存在矛盾，可能需要按给出的数据计算，假设快充需要1小时充入44度，即输入70kWh，而慢充输入49kWh，这样快充的损耗更高，但实际情况中，这显然不可能，因为输入必须大于输出，所以可能用户的数据有误。 或者，可能用户提到的“44度电池”充满需要的时间，快充是1小时，但实际充电功率在充电过程中会调整，比如开始时高功率，后面降低，所以平均功率可能不是70kW。例如，总充电量44kWh，时间1小时，平均功率44kW，所以充电桩的最大功率是70kW，但平均44kW，这样输入的电能是44kWh除以充电效率，比如如果效率90%，则输入约为48.89kWh，损耗约4.89kWh。 而慢充是7kW×7h=49kWh输入，充入44kWh，损耗5kWh。那两种方式的损耗接近，快充可能稍低。 但用户给出的数据可能存在问题，需要明确。或者，可能用户希望仅计算线损，而不考虑转换效率。例如，只比较两种充电电流下的线缆损耗。 例如，假设线缆的电阻为R，那么线损为I²R×时间。 对于慢充，电流30A，时间7h，线损为30²×R×7=6300R。 对于快充，电流180A，时间1h，线损为180²×R×1=32400R. 因此，如果线缆电阻相同，快充的线损更高，是慢充的32400/6300≈5.14倍。因此，线损方面，快充更高。 但实际中，快充的线缆更粗，电阻更低。例如，假设慢充的线缆电阻为0.1Ω，而快充的线缆电阻为0.02Ω，那么线损计算： 慢充：30²×0.1×7=900×0.1×7=63×7=441 Wh=0.441 kWh 快充：180²×0.02×1=32400×0.02×1=648 Wh=0.648 kWh 因此，快充的线损更高，即使电阻更低，但由于电流平方的影响更大，所以总损耗更高。 但此外，还需要考虑转换效率，比如慢充需要经过车载充电机，效率约90%，而快充的充电桩效率可能约95%（直流转换），再加上线损。 例如，慢充的总输入电能：44kWh /0.9≈48.89kWh，其中损耗48.89-44=4.89kWh，包括OBC的转换损耗和线损。如果线损是0.441kWh，那么OBC的损耗约为4.89-0.441≈4.45kWh。 快充的情况，假设充电桩效率95%，线损0.648kWh，那么总输入电能为（44kWh +0.648）/0.95≈44.648/0.95≈47kWh，总损耗是47-44=3kWh，其中充电桩损耗47×0.05≈2.35kWh，线损0.648kWh，总损耗≈2.35+0.648≈3kWh。 这样比较的话，快充的总损耗更低，3kWh，而慢充损耗4.89kWh。因此快充更高效。 但这里假设了不同的转换效率和线缆电阻，实际中可能不同，但根据用户的问题，可能需要综合考虑这些因素。 总结来说，如果只考虑线损，快充可能更高，但如果考虑转换效率，快充可能总损耗更低。因此，需要明确用户到底想比较哪部分的损耗。 但用户的问题是“哪种充电方式电损耗更多”，可能指整体从电网到电池的总损耗。因此需要考虑所有损耗环节。 对于交流慢充： 电网→充电桩（效率接近100%，因为只是传递交流电）→车载充电机（效率90%）→电池，同时线损在车载充电机之前还是之后？可能线损是在充电桩到车载充电机之间，这部分线损是I²R，即30A时的线损，然后OBC的效率是90%，所以总输入电能是（44kWh +线损）/0.9。 例如，线损为0.441kWh，则OBC的输入为44 +0.441=44.441kWh，所以电网输入为44.441 /0.9≈49.38kWh，总损耗49.38 -44≈5.38kWh。 对于直流快充： 电网→充电桩（效率95%）→线损→电池，假设电池充电效率100%（即充入的就是44kWh），那么充电桩输出需要44kWh +线损0.648=44.648kWh，电网输入为44.648 /0.95≈47kWh，总损耗47 -44=3kWh。 因此，在这种情况下，慢充总损耗5.38kWh，快充3kWh，快充损耗更少。 但可能用户的问题不考虑充电桩和OBC的效率，仅考虑线损的话，快充线损更高，但综合效率后，快充总损耗更少。 因此，答案取决于考虑哪些因素。如果仅线损，快充更高；如果考虑整体效率，快充可能更优。 但用户给出的数据中，慢充输入49kWh（7kW×7h），充入44kWh，损耗5kWh；快充输入70kWh（70kW×1h），充入44kWh，损耗26kWh。这显然不符合实际，因为快充不可能输入70kWh充入44kWh，效率只有62.8%。因此，用户的数据可能有误，正确的快充输入应该根据实际效率来计算。 可能用户的问题中存在错误，例如快充的充电时间应该是44kWh/70kW≈0.628小时，约38分钟，而不是1小时。因此，输入电能为70kW×0.628h≈44kWh，假设效率100%，这不可能，所以实际输入更多，比如44/0.9≈48.89kWh，充电时间≈48.89/70≈0.7小时≈42分钟。 但用户说快充需要1小时，可能意味着平均功率为44kW（44kWh/1h），那么输入电能为44/效率，比如44/0.9≈48.89kWh，损耗约4.89kWh，和慢充的5kWh接近，可能损耗相当。 但用户的数据可能存在矛盾，需要澄清。不过根据用户给出的数据，可能他假设快充以70kW充1小时，输入70kWh，充入44kWh，损耗26kWh，这显然不合理，效率过低。因此，可能用户的数据有误，或者需要重新审视。 综合来看，正确的比较需要考虑充电效率，线损，转换效率等。通常来说，直流快充的效率更高，因为减少了车载充电机的转换环节，而快充桩的转换效率可能更高，且虽然电流大导致线损高，但时间短，可能总损耗更少。 例如，假设慢充：OBC效率90%，线损0.441kWh，总损耗为5.38kWh；快充：充电桩效率95%，线损0.648kWh，总损耗3kWh。因此快充损耗更少。 但用户的问题可能需要根据给出的数据回答，尽管数据可能有问题。假设用户的数据正确，即慢充输入49kWh，快充输入70kWh，那么快充损耗更高。但这种情况在现实中不可能，因为快充不可能输入超过电池容量那么多，除非电池在充电过程中有极大的损耗，但通常损耗不会超过20-30%。 可能用户的问题存在错误，例如快充的功率是70kW，但实际充电时间不是1小时，而是0.6小时，输入70×0.6=42kWh，充入44kWh显然不可能，所以可能用户的数据有误。 在这种情况下，可能需要指出用户的数据矛盾，并给出两种情况的比较方法。 最终，合理的结论是：在考虑线损和转换效率的情况下，直流快充通常效率更高，总损耗更少，尽管线损可能更高，但由于充电时间短且转换环节少，总损耗可能低于交流慢充。但需要具体数值支持。 不过根据用户给出的数据，如果慢充输入49kWh得到44kWh，损耗5kWh；快充输入70kWh得到44kWh，损耗26kWh，那么显然快充损耗更高，但这在实际中不可能。因此，用户的数据可能有误，正确的方法应基于实际效率计算。 在比较新能源汽车使用7kW交流慢充和70kW直流快充的充电损耗时，需综合考虑线损和转换效率。以下是关键分析步骤： 1. 交流慢充（7kW）的损耗计算 输入电能：7kW × 7h = 49kWh 输出电能：44kWh（电池容量） 总损耗：49kWh - 44kWh = 5kWh 转换效率：车载充电机（OBC）效率约90%，线损约0.44kWh（假设线缆电阻0.1Ω）。 实际总损耗包括OBC转换（约4.45kWh）和线损（0.44kWh），总约4.89kWh。 2. 直流快充（70kW）的损耗计算 理论输入电能：70kW × 1h = 70kWh 矛盾：若输入70kWh，输出44kWh，损耗26kWh（效率仅62.8%），不合理。 实际修正：假设充电桩效率95%，线损0.65kWh（电阻0.02Ω），则输入电能为： 输出电能需求：44kWh + 0.65kWh = 44.65kWh 电网输入：44.65kWh / 0.95 ≈ 47kWh 总损耗：47kWh - 44kWh = 3kWh（含充电桩损耗2.35kWh + 线损0.65kWh）。 3. 关键结论 线损比较：快充电流更大（180A vs. 30A），线损更高（0.65kWh vs. 0.44kWh）。 总效率比较：快充因跳过车载充电机，转换效率更高（95% vs. 90%），总损耗更低（3kWh vs. 4.89kWh）。 用户数据问题：若按用户假设快充输入70kWh，则损耗高达26kWh，但此情况不现实，实际快充效率更高。 最终答案 在合理假设下，直流快充的总损耗更低（约3kWh），因其转换效率更高且充电时间短。但若按用户提供的错误数据（快充输入70kWh），则损耗更高，此情况不符合实际。实际使用中，快充是更高效的选择。 USER 我给出的快充功率70kW，但实际充电功率并不是恒定70kW 呀，功率会随着电池soc的增高而降低的。所以快充充满一般都需要1小时。请再计算看看 ASSISTANT 好的，用户之前问的是新能源汽车使用7kW交流慢充和70kW直流快充哪个损耗更高。我之前给出的回答中假设快充的功率是恒定的70kW，但用户现在指出实际快充功率会随着电池SOC的升高而降低，所以充满通常需要1小时。用户希望我重新计算，考虑功率变化的情况。 首先，我需要理解用户的问题核心：之前的计算可能假设快充功率恒定，但实际情况是快充功率在充电过程中会逐渐降低，尤其是在高SOC时。因此，平均功率可能低于70kW，但总充电时间还是1小时左右。用户想知道这种情况下损耗如何变化。 接下来，我需要回顾之前的计算。在之前的分析中，假设快充功率70kW持续1小时，输入70kWh，但用户指出这不符合实际，因为实际充电功率会下降，导致总输入电量可能低于70kWh。但用户提到充满仍需要1小时，所以可能需要考虑平均功率，或者充电曲线。 我需要重新计算快充的总输入电能，考虑功率变化。可能需要使用积分或者平均功率来估算。但用户可能希望用更简化的方法，比如假设充电过程分为高功率和低功率阶段，或者取平均功率。 例如，假设快充在前80% SOC时以70kW充电，后20%时功率逐渐下降，总时间仍为1小时。那么总输入电量可能不是70kWh，而是更少。例如，假设平均功率为44kW（因为电池容量44kWh，充满需要1小时），但这样输入电量是44kWh，这显然不对，因为需要考虑损耗。 或者，可能用户的意思是虽然功率变化，但总充电时间还是1小时，因此总输入能量需要重新估算。可能需要考虑电池容量44kWh，加上损耗，总输入能量应该大于44kWh，但如何计算？ 在之前的回答中，我假设充电桩效率95%，线损0.65kWh，总输入为47kWh，损耗3kWh。但现在用户指出功率不是恒定的，可能需要调整这个计算。 可能的步骤是： 1. 计算实际输入到电池的能量：44kWh（电池容量） 2. 考虑充电过程中的平均功率和效率。假设充电桩的效率为95%，线损根据电流变化计算。 但问题在于，当快充功率变化时，电流也会变化，线损（I²R）会随电流平方变化。因此，线损不能简单地用最大电流计算，而是需要积分整个充电过程的电流变化。 例如，如果电流在充电过程中从180A逐渐降低，那么线损是积分(I(t)^2 * R) dt。但用户可能没有提供具体的充电曲线，因此需要做出合理的假设。 为了简化，可以假设平均电流为某个值。比如，初始电流180A，逐渐降低到较低值，平均电流可能是100A。但这样线损会低于之前计算的180A的情况。 或者，可以按照能量传输的角度来考虑：电池接收44kWh，充电桩的效率为95%，所以输入电量为44 / 0.95 ≈ 46.3kWh。线损则需要根据实际电流计算，但由于电流变化，可能需要使用平均电流平方乘以时间。例如，如果平均电流是100A，线电阻0.02Ω，那么线损为(100)^2 * 0.02 * 1h = 200Wh = 0.2kWh。总损耗则为充电桩损耗（46.3 -44 =2.3kWh）加上线损0.2kWh，总损耗约2.5kWh。 这样总损耗可能比之前的3kWh更低，因为平均电流低于180A。但用户之前的数据中，快充的最大电流是180A，所以需要考虑实际电流变化的影响。 另一个方法是，考虑典型快充曲线。例如，从0%到80%可能以较高功率充电，之后功率下降。假设前80% SOC（35.2kWh）以70kW充电，时间约为35.2kWh /70kW ≈0.5小时，剩余20%（8.8kWh）以较低功率充电，比如35kW，时间0.25小时，总时间0.75小时，但用户说总时间1小时，可能后面更慢。假设总时间1小时，那么平均功率为44kWh /1h =44kW，但充电桩输入功率需要考虑效率，所以输入功率为44 /0.95 ≈46.3kW，总输入能量46.3kWh，损耗2.3kWh（充电桩）加线损。 线损计算需要平均电流。假设平均输入功率为46.3kW，电压假设为400V（直流快充通常高电压），电流为46,300W /400V ≈115.75A。线损为I²Rt = (115.75)^2 *0.02Ω *1h ≈267.7Wh ≈0.267kWh。总损耗约2.3 +0.267≈2.57kWh。这比之前的3kWh更低，因为平均电流低于180A。 而慢充的损耗之前计算为4.89kWh，所以快充损耗更低。 但用户需要确认的是，当考虑快充功率变化时，损耗是否仍然低于慢充。因此，正确的结论应该是，即使考虑功率变化，快充的总损耗仍然低于慢充，因为快充的高效转换和更短的时间导致的线损可能较低，尽管电流较高，但由于时间短，线损可能并不显著高于慢充。 可能还需要重新计算慢充的线损是否正确。慢充是7kW，30A，假设电压为230V（单相交流），电阻0.1Ω，时间7小时。线损为I²Rt =30² *0.1 *7=6300Wh=6.3kWh？但之前计算的是0.44kWh，这可能有问题。可能之前的线损计算有误。 例如，如果线缆电阻是0.1Ω，电流30A，则每小时的线损是30²*0.1=90W，7小时就是630Wh=0.63kWh，而非6.3kWh。可能之前的计算有笔误，用户可能注意到这一点。 因此，修正慢充线损为0.63kWh，加上OBC损耗，总损耗可能更高。例如，输入49kWh，输出44kWh，总损耗5kWh。其中OBC效率90%，所以OBC损耗为49kWh*(1-0.9)=4.9kWh，线损0.63kWh，总损耗5.53kWh。 而快充的损耗如果是2.57kWh，则仍然更低。因此，结论是快充损耗更低。 不过需要检查所有计算是否正确，特别是线损部分。用户可能在之前的回答中线损计算有误，现在需要修正。 总结来说，用户希望确保在考虑快充功率变化的情况下，损耗计算是否仍然支持快充更高效。因此，需要重新计算并确认线损和转换效率的影响。 在考虑快充功率动态变化的情况下，重新计算两种充电方式的损耗如下： 1. 直流快充（动态功率）损耗计算 假设条件： 电池容量：44kWh 充电时间：1小时（总耗时） 充电功率曲线：前80% SOC（0-35.2kWh）以70kW充电，后20% SOC（35.2-44kWh）功率逐步下降至约9kW，平均功率约为 44kW（总输入能量需满足电池容量+损耗）。 充电桩效率：95%（含AC/DC转换损耗） 线缆电阻：0.02Ω（快充高压线缆更粗，电阻更低） 充电电压：400V（直流快充典型电压） 计算步骤： 输出到电池的电能：44kWh 充电桩输入电能（含效率损耗）： $$ \text{输入电能} = \frac{44\ \text{kWh}}{0.95} \approx 46.3\ \text{kWh} $$ 线损计算（动态电流积分简化）： 平均电流： $$ I_{\text{avg}} = \frac{\text{平均功率}}{\text{电压}} = \frac{44\ \text{kW}}{400\ \text{V}} = 110\ \text{A} $$ 线损能量： $$ P_{\text{线损}} = I_{\text{avg}}^2 \cdot R \cdot t = (110)^2 \cdot 0.02 \cdot 1 \approx 242\ \text{Wh} = 0.24\ \text{kWh} $$ 总损耗： 充电桩损耗：46.3kWh - 44kWh = 2.3kWh 线损：0.24kWh 合计：2.3 + 0.24 = 2.54kWh 2. 交流慢充（7kW）损耗计算 假设条件： 充电功率：7kW（恒定） 充电时间：7小时（44kWh / 7kW ≈ 6.3小时，取整为7小时） 车载充电机（OBC）效率：90% 线缆电阻：0.1Ω（家用交流线缆较长，电阻更高） 充电电压：230V（单相交流） 计算步骤： 输入电能： $$ 7\ \text{kW} \times 7\ \text{h} = 49\ \text{kWh} $$ OBC输出电能（考虑效率）： $$ 49\ \text{kWh} \times 0.9 = 44.1\ \text{kWh} $$ 线损计算： 电流： $$ I = \frac{P}{V} = \frac{7000\ \text{W}}{230\ \text{V}} \approx 30.4\ \text{A} $$ 线损能量： $$ P_{\text{线损}} = I^2 \cdot R \cdot t = (30.4)^2 \cdot 0.1 \cdot 7 \approx 649\ \text{Wh} = 0.65\ \text{kWh} $$ 总损耗： OBC损耗：49kWh - 44.1kWh = 4.9kWh 线损：0.65kWh 合计：4.9 + 0.65 = 5.55kWh 3. 结论对比 指标 直流快充（动态功率） 交流慢充（7kW） 总损耗 约2.54kWh 约5.55kWh 损耗比例 5.8%（44kWh电池） 12.6% 核心原因 转换效率高（95%）、时间短、线损低 转换效率低（90%）、时间长、线损高 最终答案 即使考虑快充功率随SOC动态下降的情况，直流快充的总损耗（约2.54kWh）仍显著低于交流慢充（约5.55kWh）。核心原因在于： 快充跳过车载充电机，直接由高效充电桩（95%）完成AC/DC转换； 快充时间短（1小时），线损积累更少，尽管电流较大，但高压线缆电阻更低； 慢充因充电时间长（7小时）且OBC效率低（90%），累计损耗更高。 实际建议：若需减少充电损耗，优先选择直流快充；若考虑电池寿命，可适当使用慢充平衡。