因为内容相关性较差本文没有发表在Linux用户站。

DeepSeek V4正式版来了，但只来了一半：Flash版“倒反天罡”，Agent能力暴打Pro预览版

xfox.fun/archives/{cid}/

因为内容相关性较差本文没有发表在 Linux 用户站

2026年7月31日午后，DeepSeek通过API文档发布日志，宣布DeepSeek-V4-Flash正式版API上线公测。消息一出，DeepSeek迅速冲上知乎热搜第一。

但与常规认知中“Pro强、Flash弱”的分层逻辑完全不同——这次Flash正式版在Agent能力上实现了对自家Pro预览版的全面反超。

一、“倒反天罡”：Flash凭什么暴打Pro Preview？

DeepSeek-V4-Flash正式版（模型版本号DeepSeek-V4-Flash-0731）的模型结构、尺寸与预览版完全一致——总参数2840亿，激活参数仅130亿。官方表示，仅重新进行了后训练。

就是这个“仅重新进行了后训练”，带来了质的飞跃。官方公布的9项Agent基准测试成绩如下：

最夸张的是DeepSWE测试——从预览版的7.3分暴涨到54.4分，性能提升超过6倍。而V4-Pro预览版在Terminal Bench 2.0上的得分仅为67.9分。

虽然Terminal Bench 2.0与2.1并非同一版本测试集，直接对比不完全公平，但一个激活参数仅130亿的轻量版模型，在Agent能力上跑出这样的分数，已经足够说明问题：后训练阶段的优化空间，可能比单纯堆参数更具杠杆效应。

海外模型评测机构Artificial Analysis在7月31日更新的智能指数测试中，给予V4-Flash-0731（最高推理档位）50分，在同类可比模型中明显高于平均水平（可比模型的中位数为17分）。

二、后训练仙人：同样的骨架，不同的灵魂

这次升级的技术路径值得深思。

DeepSeek官方明确表示，V4-Flash-0731的模型结构和尺寸与预览版完全一致，仅重新进行了后训练。这意味着DeepSeek在训练方法和数据质量上找到了突破口——同样的模型“骨架”，经过更精细的训练策略调优，就能在基准测试中产生质的飞跃。

DeepSeek-V4-Pro总参数1.6万亿，激活参数490亿；V4-Flash总参数2840亿，激活参数130亿。两者在模型规模上相差一个数量级。如果Flash能通过后训练把Agent能力拉到接近Pro预览版的水平，那意味着对于特定任务而言，模型规模并非决定性因素。

网友评论精辟：“DeepSeek这一波真的是后训练仙人了”。

此外，官方还特别注明，公开基准测试中的Code Agent任务使用了DeepSeek Harness极简模式作为框架进行测试。这是DeepSeek官方自研Harness首次以正式命名出现。据透露，DeepSeek的Harness团队组建于今年3月，挂帅者崔添翼是90后，浙大计算机出身，手握6枚ACM亚洲区域赛金牌。

三、生态暗战：原生支持Responses API，适配Codex

这次更新另一个值得关注的信号是生态层面的布局。

正式版V4-Flash原生支持Responses API格式，并针对性适配了Codex。Responses API是OpenAI用于统一处理模型输出、推理过程和工具调用的一套接口格式，也是Codex客户端与模型交互的主要接口之一。现在，开发者可以在Codex CLI、ChatGPT桌面端和VS Code的Codex插件中，将DeepSeek配置为模型提供方。

这意味着DeepSeek正在从模型层向工具链层渗透。目前Responses API只支持V4-Flash，V4-Pro预计8月初接入。

四、资本加持后的第一次技术兑现

这次升级距离DeepSeek完成首轮融资不到两个月。今年6月，DeepSeek完成首轮外部融资，总额超74亿美元（约合500亿元），投后估值超500亿美元（约合3380亿元） ，创下中国AI行业单轮融资纪录。

资本加持下的第一次技术兑现，Flash版交出了一份令人瞩目的成绩单。

五、美中不足：只来了一半

当然，也有一些遗憾。

本次升级仅限于DeepSeek-V4-Flash的API接口，DeepSeek-V4-Pro API及APP/WEB端模型均未做更改。大家常用的App和网页端暂时无法体验最新能力。

DeepSeek表示，V4-Pro正式版将会“尽快发布” 。有消息称V4-Pro预计8月初正式发布。

网友已经开始期待：“V4-Flash已经这么强，真不敢想象V4-Pro会有多强！该不会是明天吧！？”

六、行业视角：Agent战争的大幕刚刚拉开

如果说2023年的大模型竞争是“拼通用能力”，2024年是“拼长上下文”，那么2026年的关键词，毫无疑问是Agent。

Agent能力——即模型自主规划、调用工具、执行复杂任务的能力——正在成为衡量大模型实力的新标尺。从全球范围看，Agent能力的第一梯队目前仍由闭源巨头把持。但DeepSeek-V4-Flash正式版在多项Agent基准上的表现已经逼近Opus 4.8，而价格只有Claude的1/90。

有网友让GPT整理了V4 Flash对比其他大模型的性能测试，结论是性价比上Flash依然无敌，比降价后的GPT-5.6 Luna还要少一半的费用。

V4-Flash只用1/10到1/3的参数量就做到了前沿级性能。而V4-Pro是1.6万亿参数量，规模大了4倍以上。按照这个幅度来算，V4-Pro正式版的性能达到甚至超过K3、Opus 5、GPT-5.6 Sol都是有可能的。

总结： 2026年7月31日，DeepSeek-V4-Flash正式版API上线公测。Flash版以2840亿总参数、130亿激活参数的“小身板”，在9项Agent基准测试中全面超越V4-Pro预览版，DeepSWE测试更是从7.3分暴涨至54.4分，性能提升超6倍。同时原生支持Responses API并适配Codex，生态野心初显。V4-Pro正式版预计8月初发布——Flash已经这么强了，Pro得有多猛？

本文数据来源：DeepSeek官方API更新日志、IT之家、凤凰网科技、观察者网、快科技等

你可能已经发现我的Mastodon上刷了一大串帖子，这正是刚才测试文章同步造成的。

同步使用了项目：FediverseSyncForTypecho 原始仓库为：jkjoy——FediverseSyncForTypecho
原仓库不支持使用代理完成网络请求，使得该插件在某些Mastodon站点被GFW屏蔽的情况下完全无法使用。
我的仓库把Release版本号刷到了1.6.5 主要增加了对http和socks5代理的支持。也是顺便测试借助DeepSeek 彻彻底底Vibe Coding了一回，确实很方便，花小钱办大事，比自己慢慢扣效率高太多了。

本次Vibe Coding使用Visual Studio Code搭配DeepSeek V4 for Copilot Chat

这个项目我自从看到GS在用就注意到了，当时就下载测试发现不支持代理试图自己添加代理支持（简单写死的）可惜学艺不精没一直扣完，太简陋不想公开最终拖到了今天。
我已经尽自己所能的审查了AI生成的代码，但是为了避免Vibe Coding可能潜在的混乱和污染问题，这个仓库的更新我不会推送到原始仓库，就让本项目作为我的个人试验品好了

具体更新如下：

Fediverse Sync for Typecho - 更新日志

版本 1.6.5 (2026-06-18)

新增功能

• SOCKS5/HTTP 代理支持

  • 新增可选代理配置，支持 HTTP 和 SOCKS5 两种代理类型
  • SOCKS5 使用远端 DNS 解析（CURLPROXY_SOCKS5_HOSTNAME），避免 DNS 污染
  • 支持代理认证（用户名/密码）
  • 适用于中国大陆等网络受限环境

重构优化

• HTTP 请求统一重构

  • 将分散在 Plugin.php、Action.php、Api/Sync.php 中的 6 处原始 cURL 调用集中到 Utils/Http.php
  • 新增 postForm() 方法，统一处理 Mastodon/GoToSocial 的表单编码 POST 请求
  • Header 去重处理，避免重复 header 导致 400 错误
  • 代理逻辑由 Utils/Proxy.php 集中管理，一处配置全局生效

调试改进

• 增强 HTTP 层错误日志

  • 请求失败时自动记录 URL、HTTP 状态码、cURL 错误号和错误描述、响应体预览
  • Proxy 应用代理时记录代理类型和地址，便于确认代理是否生效

文件结构

FediverseSync/
├── Utils/
│   ├── Proxy.php           # 增强：支持 SOCKS5+HTTP 代理类型选择
│   └── Http.php            # 增强：新增 postForm() + 代理集成 + 日志增强
└── Plugin.php              # 新增5个代理配置项

在关闭Frp的tcp mux 后上传才正常持续，之前是小文件可以秒传卡100%，大就传一下等待一会儿就报错Network Error（仅使用Frp进行端口转发的情况下）如果再加上Nginx进行反向代理没有写明超时时间，默认60s就更完蛋了，给你报405/502/504等一串错误。
HK 大陆3网直连 200Mbps的VPS做转发，一个30MB的文件1MB分片已经传了十几分钟了，真的逆天啊我很难想想这性能瓶颈到哪里了，哪怕作为下载方的家宽服务器现在也有100Mbps下行，我本地直接5G流量居然还是这么龟速。 纯纯逆天。
折腾这个玩意真的让我力竭了，当然力竭的倒霉蛋也不只我一个，互联网上随手就能搜到类似的问题，而且最终说是解决的实际和没解决也区别不大，依旧是慢如蜗牛。

先来谈谈Frp TCP多路复用的降速问题

看个帖子：tcpmux 会大幅降低链路速度#2987
看完你应该大致明白发生了啥，总之开发者们选择了稳定性，但是这在我的应用场景就很糟糕。
所以我最终选择了关闭TCP MUX。

Nginx 反代对Cloudreve的影响

首先，我刚才提过Nginx对前后端的默认的连接超时都是60s一超时就给前端返回504，所以你要么60s内传完，要么保障断开连接后自动重连。
当然，我们还有个更具备实操价值的办法😉：

  location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host; 
        proxy_redirect off;
        proxy_pass http://127.0.0.1:5212;  
        proxy_request_buffering off; # 禁用反向代理缓存
        proxy_read_timeout 3600s;   # 等待后端响应超时
        proxy_send_timeout 3600s;   # 发送请求体给后端
        client_body_timeout 3600s;  # 接收客户端请求体
        send_timeout 3600s;         # 发送响应给客户端

        client_max_body_size 0;     # 0 表示不限制请求体大小
    }

分片大小

在带宽足够的情况下，为了充分吃满带宽分片大小应该尽可能的大以提高[所求数据传输时间/协议开销时间]的值，拆分成小块发送意味着花费更多的时间在协议开销上。具体大小应该根据你自己的各级服务器带宽决定，如果带宽本身就很低或者波动明显，就适当调小维持稳定上传状态。
对于我的200Mbps上行的Frps和30上/100Mbps下的Frpc 我选择的分片大小是16MB。

Frps与Frpc 之间的协议效率

在理想的情况下，QUIC一定是最好的选择，如果网络波动明显只能退选KCP。但是考虑到实践中某些运营商对UDP流量极端的QoS策略，我只能选择TCP和基于TCP的协议。
在某些特殊环境下，开启流量加密是你不得不做的选择，但是如无必要加密和压缩两个都没有必要开，特别是设备cpu性能明显羸弱的情况下，开启流量压缩没有任何意义。

最后，看看更接近操作系统底层的地方

Linux之TCPIP内核参数优化

懒人方案：决定24H不睡迎接中秋节——顺便修一修linuxuser.site邮件服务器的严重不可用问题

2026-08-09更新

明确一件事：FRP转发降速的根本原因你的稳定网络带宽并没有像IDC承诺的那样高！

通过iperf3 反复测速发现，NAS和Frp Server的链路速度中ipv4 udp是延迟和速度最佳的，因此我选择避免NAS frpc客户端使用ipv6连接 服务器。
其次，iperf3以不同限速条件测试还发现：
上行（本地→服务器）：在 50Mbps 时丢包率仅 0.038%，但达到80Mbps时丢包率骤升至 28%，说明上行安全极限约为 50Mbps。
下行（服务器→本地）：虽然极限能跑到 90Mbps 左右，但丢包率达 8.6%，为了稳定性调整限制在 70Mbps 以内。
一旦超出速率就面临30%的丢包率。为了避免高丢包对链路连接稳定性和重传概率的干扰，我选择切换到KCP模式，固定速率48Mbps，同时发现由于早前禁用TCP连接复用导致正常环境下访问cloudreve 短时间内静态资源和API请求会占用大量连接出现 frp备用连接池不足的问题。
2026-08-09 00:07:05.086 [E] [client/control.go:144] [da4d5ef29b0299e1] StartWorkConn contains error: work connection pool is full, discarding

因此tcp连接复用还是要开启的，当然也许理论上坚持手动调大预备连接池也能解决问题，但是考虑到国内运营商对家宽的连接数限制，最好降低连接数避免过高连接数触发QoS 影响链路稳定性。
同时为了降低对NAS G4600 CPU较为有限的资源占用，我没有采取vHost 代理模式，而是直接将cloudreve 的5212端口tcp通过FRP代理到HK Frp Server本地，然后原地建立Nginx反代，将TLS开销完全丢给HK Frp Server。
在经过上述调整后，测试上传的100MB文件上传进度均匀稳定，没有卡在100%，并且基本可以顶至预设的6MB/s限速最终稳定在5Mbps。（也符合百兆家宽普遍的上下行规律 QoS限制内的冗余值设置在40~50Mbps 实际机房链路预期为30~40Mbps。）

为什么同为UDP 谷歌宣传更好的QUIC反而不如KCP？

QUIC 强制 TLS1.3 加密握手开销大，且其默认的拥塞控制算法CUBIC基于丢包设计，一旦检测到丢包会激进地降低发送速率。家宽受运营商跨网和固有机房节点设备性能限制本就处于较高丢包率的网络环境中，CUBIC 会频繁地触发降速机制，导致吞吐量骤降无法像 KCP 那样快速重传，导致转发Cloudreve流量时出现严重的连接超时和假死问题。
具体配置分享如下：

Frpc 配置部署于 NAS 中国联通家宽

serverAddr = "149.104.5.21"
serverPort = 7000
auth.token = "null"

# 全局传输协议
transport.protocol = "kcp"
#transport.tcpMux = false

# ====== 代理列表 ======

# -------------------
# xfox.fun 主站
# -------------------
[[proxies]]
name = "xfox.fun"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["xfox.fun", "www.xfox.fun"]
transport.bandwidthLimit = "6MB"

# -------------------
# linuxuser.site 主站
# -------------------
[[proxies]]
name = "linuxuser.site"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["linuxuser.site", "www.linuxuser.site"]
transport.bandwidthLimit = "6MB"

# -------------------
# NAS 页面
# -------------------
[[proxies]]
name = "nas.xfox.fun 5212"
type = "tcp"
localIP = "127.0.0.1"
localPort = 5212
remotePort = 5212
#transport.useEncryption = true
#transport.useCompression = true
#如果你认为你的客户端设备性能较强你可以考虑开启压缩，但是个人不推荐同时启用压缩和加密（理论上显著增加链路延迟）
transport.bandwidthLimit = "6MB"

Frps 配置 部署于HK三网直连优化服务器

indAddr = "::"
bindPort = 7000
vhostHTTPPort = 按需随意
#vhostHTTPSPort = 8443

# 原 QUIC 监听端口（如果你不再用 QUIC，可以注释掉；保留也无妨，但本次客户端不用）
# quicBindPort = 7000

# KCP 监听端口（与 bindPort 一致，这样客户端无需指定额外端口）
kcpBindPort = 7000

auth.token = "null"
#transport.tcpMux = false
# 以下配置随意
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "你的用户名"
webServer.password = "你的密码"

Nginx 反代配置 部署于HK三网直连优化服务器

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name nas.xfox.fun;
    http2 off;
    # SSL 证书路径按需随意，以下示例仅供参考
    ssl_certificate /root/www/all_xfox.fun/fullchain.pem;
    ssl_certificate_key /root/www/all_xfox.fun/privkey.pem;

    # ========== SSL 配置 ==========
    ssl_protocols TLSv1.2 TLSv1.3;  
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_ecdh_curve X25519:secp384r1;  
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    # ====================================

    root /var/www/tv.linuxuser.site;
    index index.html;


    location / {
    # ========== 基础代理头 ==========
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    # ========== 后端地址 ==========
    proxy_pass http://127.0.0.1:5212;

    # ========== 超时设置 ==========
    proxy_request_buffering off;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    client_body_timeout 3600s;
    send_timeout 3600s;
    client_max_body_size 0;

    proxy_connect_timeout 75s;                # 连接后端超时（默认60s，适当延长）
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    proxy_next_upstream_tries 3;              # 允许重试3次
    proxy_next_upstream_timeout 30s;          # 重试总时间限制
    proxy_http_version 1.1;
    proxy_set_header Connection "";

           }
}

写在末尾

TCP连接复用在运营商QoS环境下本身并不稳定，中途可能导致连接中断，进一步造成上传文件卡住假死的问题。因此你应该根据实际iperf3测试得到的低丢包率稳定的上下行带宽完成配置。理论上，TCP连接复用也并不能彻底解决连接池占满的问题，所以你也可以尝试关闭TCP连接复用并继续增大连接池数量到适宜水平。

言归正传主要错误有两个：

第一个：
Invalid API Response: The provider returned an empty or unparsable response. This is a provider-side issue where the model failed to generate valid output or returned tool calls that Cline cannot process. Retrying the request may help resolve this issue.
第二个：
Cline uses complex prompts and iterative task execution that may be challenging for less capable models. For best results, it's recommended to use Claude 4 Sonnet for its advanced agentic coding capabilities.

这俩问题我是最近几天才发现的，并且都没有在github找到有实际有意义的解决方案，所以我不得不考虑一下报错描述的内容所明示的：你API有问题返回值不对劲
去DeepSeek的最近更新的文档看了一下，果然发现端矣：DeepSeek-V3.2 正式版发布 2025/12/01

DeepSeek-V3.2 的思考模式也增加了对 Claude Code 的支持，用户可以通过将模型名改为 deepseek-reasoner，或在 Claude Code CLI 中按 Tab 键开启思考模式进行使用。但需要注意的是，思考模式未充分适配 Cline、RooCode 等使用非标准工具调用的组件，我们建议用户在使用此类组件时继续使用非思考模式。
但请注意，当我们的服务器承受高流量压力时，您的请求发出后，可能需要等待一段时间才能获取服务器的响应。在这段时间里，您的 HTTP 请求会保持连接，并持续收到如下格式的返回内容：
非流式请求：持续返回空行
流式请求：持续返回 SSE keep-alive 注释（: keep-alive）

这就很蛋疼了，原来Cline你才是爱用非标件的那个大傻逼🤣啊，结合GitHub看到的prompt代码，Cline是直接搞了一堆非标准的标签让后端识别，如果API供应商不做额外的专门训练那回复的准确率可就完全没保障了。至于对等待响应的处理，暂时不清楚Cline有没有做。
所以理论上要么换Claude Code插件要么用非思考模型（其实用着感觉也还行）。
当然还有个比较邪修的操作，用国内某某API小厂赞助的其他Cline汉化版插件，通过git历史提交可以看到他们把非标的标签连带prompt全翻译成中文，这时候DS思考模式回复的正确率确实大大提高，但是某API厂商的广告就有点烦人了😅（这个版本还暗戳戳把DS官方的选项里上下文改成64K砍了一半，估计也是为了方便多点碰壁的好卖他的API），另外频繁使用全中文prompt将会明显增加API的固定开支。
所以拉倒吧我还是用原版。

这个想法自从我开始使用Pmail就有了但是一直因为各种原因没有实现。

初步预期

尽可能在不额外进行训练/微调的情况下使用RWKV（这我熟啊.webp)的小体积模型结合提示词与预设上下文对输入邮件进行处理返回一个带有概率值的JSON数值，该数值将作为入站邮件处理API的返回值传递给Pmail。
最终达到在较低算力及内存资源的边缘设备（如自组NAS）上完成对个人或小组织级别邮件服务的垃圾邮件处理。

数据结构

为了便于Pmail使用，请求格式及返回值按照：PMail/server/hooks/spam_block/的数据结构：
请求：

curl -X POST http://localhost:8501/v1/models/emotion_model:predict -d '{ 
    "instances": [
        {"token":["各位同事请注意 这里是110，请大家立刻把银行卡账号密码回复发给我！"]}
    ]
}' 

输出：

{
  "predictions": [
    [
      0.394376636,
      // 正常邮件的得分
      0.0055413493,
      // 广告邮件的得分
      0.633584619
      // 诈骗邮件的得分，这里诈骗邮件得分最高，因此最可能为诈骗邮件
    ]
  ]
}

静域信驿

静域信驿（Tranquil Inbox Ward）

~~静域信驿（Tranquil Inbox Ward），专为 pmail 设计的关键词增强型垃圾邮件分类服务（规则 + LLM 混合）。
扒拉邮箱的垃圾邮件测试了很久，还是决定使用关键词加权结合LLM分类完成，因为测试发现较小的模型分类效果尚可，但直接要求给出三个分类各自的期望值效果就很差，即便使用较大规模的模型也难以通过提示词达到预期效果。（也可能我提示词写太烂....sad)按照项目预期，我打算让他跑在NAS的集成显卡上而不是AI性能更显羸弱的CPU上，这就要求必须尽可能使用更小体量的模型。~~
目前已经模块化重构并迭代到0.0.2具备基本可用性，欢迎各位PMail用户进行测试。

目前还有很多乱七八糟的问题，需要慢慢发现并解决，当然————欢迎PR

前段时间我去爬山，回来写了文章：朱雀国家森林公园痛苦一日游
上传图片的时候发现当前时代的浏览器并不支持浏览HEIF格式的图片，但是这一标准在苹果和许多较新安卓设备上都已经开始推广，并且压缩率不错，所以能不能想办法让浏览器显示HEIF格式的图片呢？

找到所需开源项目：

hoppergee/heic-to Convert HEIC/HEIF images to JPEG, PNG in browser
我的需求显然早就有人在做了，这个项目利用javascript提供了一个在前端将HEIF格式图片转换成jpeg/png的方案。

引用heic-to

工作原理：

1. 自动检测所有带有.heic或.HEIC扩展名的图片
2. 使用fetch API获取原始HEIC文件
3. 在浏览器中转换为JPEG格式
4. 替换图片的src属性显示转换后的图片

<script type="module">
// 导入CSP安全版本的HEIC转换模块 需要支持ES6特性
import { heicTo } from 'https://cdn.jsdelivr.net/npm/heic-to@1.2.1/dist/csp/heic-to.js';

document.addEventListener('DOMContentLoaded', async function() {
    // 检查浏览器是否支持所需API
    if (!window.fetch || !window.URL || !window.Blob) {
        console.warn('浏览器不支持HEIC转换所需API');
        return;
    }
    
    // 处理HEIC图片转换
    async function processHEICImages() {
        const images = document.querySelectorAll('img[src$=".heic"], img[src$=".HEIC"]');
        if (images.length === 0) return;
        
        console.log(`找到 ${images.length} 张HEIC图片，开始转换...`);
        
        for (const img of images) {
            const src = img.src;
            const originalAlt = img.alt || '';
            const originalClass = img.className;
            
            try {
                // 添加加载状态
                img.alt = 'HEIC图片转换中...';
                img.classList.add('heic-loading');
                
                // 获取HEIC文件
                const response = await fetch(src);
                if (!response.ok) throw new Error(`HTTP错误! 状态码: ${response.status}`);
                
                const blob = await response.blob();
                
                // 转换为JPEG
                const jpegBlob = await heicTo({
                    blob: blob,
                    type: "image/jpeg",
                    quality: 0.8
                });
                
                // 创建对象URL并替换
                const jpegUrl = URL.createObjectURL(jpegBlob);
                img.onload = function() {
                    URL.revokeObjectURL(jpegUrl); // 释放内存
                    img.classList.remove('heic-loading');
                    img.classList.add('heic-converted');
                };
                img.src = jpegUrl;
                img.alt = originalAlt;
                img.className = originalClass;

            } catch (err) {
                console.error('HEIC转换失败:', err);
                img.alt = originalAlt + ' [HEIC转换失败]';
                img.classList.remove('heic-loading');
                img.classList.add('heic-error');
            }
        }
    }
    
    await processHEICImages();
});
</script>

<style>
.heic-loading {
    position: relative;
    min-height: 100px;
    background: #f5f5f5 url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"><circle cx="50" cy="50" r="40" stroke="%233498db" stroke-width="8" fill="none" stroke-dasharray="62.8 188.8"><animateTransform attributeName="transform" type="rotate" repeatCount="indefinite" dur="1s" values="0 50 50;360 50 50" keyTimes="0;1"></animateTransform></circle></svg>') no-repeat center;
    background-size: 50px;
}
.heic-converted {
    border: 2px solid #2ecc71;
}
.heic-error {
    border: 2px dashed #e74c3c;
}
</style>

使用方法：

你可以引用上面的代码到任意html页面，通常我们把他放在header或footer里。
在Typecho上我们可以把它放在主题文件的： header.php 中

本文代码已在Github以MIT协议开源，感谢自由软件与开源社区！
DisplayMyHEIC

测试图片

作者: 未知狐 时间: 2025-4-18 分类: 随手记,Linux,趣分享,时间轴,折腾=-=
你是否正在使用沉浸式翻译？或者划词翻译？
前者可以通过开发者模式直接填写使用Deeplx ，而后者则不能直接兼容Deeplx API，需要根据划词翻译的自定义API格式对请求作转换处理，我们这里就使用到了Hcfy-Deepl Translation Adapter完成这一处理过程。

本文的免费原理：Claw Cloud 为注册用户免费提供5美元免费额度，其中Github账户注册时长180天以上的用户还可以每月免费获得5美元免费额度，因此我们可以利用免费额度运行一些资源占用较低的服务，比如：Deeplx及Hcfy-Deepl Translation Adapter
让沉浸式翻译用上Deeplx
仅限Linux.do用户使用：
[喂饭教程] 始皇connect里的DeeplX Key搭配沉浸式翻译
所有用户可用：
首先还是去注册ClawCloud（下面有链接）,位置无所谓，随便选一个地区。
然后在App Store里搜索找到：DeepLX
部署后在App Launchpad -> My APP里找到deeplx-xxxx 项目直接点击进入配置页面
Network(1) -> Public Address 复制下方的DeepLX服务地址公网API访问地址。
该地址不能被划词翻译直接使用，但是可以被其他支持DeeplX API的项目使用。

白嫖Claw Cloud 运行Hcfy-Deepl Translation Adapter 让划词翻译用上Deeplx 翻译！
首先用去注册Claw Cloud
注册完成后跳过用户指引，直接点击 App Launchpad -> Create App 即可。
应用名称 （Application Name） 默认为：hello-world 改为：hcfy-deeplx-bridge
镜像名称 （Image Name） 改为：nerdneils/deeplx_adapter_for_hcfy:latest
接着我们需要调整资源占用降低服务费用到免费额度内。
Usage ：
Replicas 1
CPU 0.1 Core
Memory 64 M
Network：
Container Port ：9911
启用互联网访问(Enable Internet Access) 选项一定要开启。
额外选项 (Advanced Configuration)
环境变量 (Environment Variables): 点击+Add 添加如下内容：
DEEPLX_ENDPOINT 你的DeepLX服务地址一般类似(https://xxx.com/translate）
DEEPLX_NAME deeplx
注意中间空格，随后点击右上角Delpy Application部署应用即可。
然后你就可以得到一个名为hcfy-deeplx-bridge的应用，点进去复制Public Address 下方的公网API地址即可。

安装划词翻译后
进入划词翻译设置页面划词翻译-自定义翻译源
输入我们刚得到的公网API地址，翻译源名称填写：deeplx 并回车。
接着恭喜你完成了所有白嫖过程，现在可以使用浏览器插件通过DeepL翻译任何你想要翻译的内容了！

标签: none

仅有一条评论
EricQwQEricQwQ
2025年4月20日19:31
看到专属还以为是什么会员制社区（吓

回复

今天是2025年1月16日星期四 ，欢迎来到硬核灌水，以下是本期的主要内容。

Fedora 42 正在考虑将其Live安装镜像切换到 EROFS

来源： Michael Larabel

Fedora 42 计划将其 live 安装镜像的文件系统从 SquashFS 切换为 EROFS，这项提案今天已提交。当前 Fedora Linux 的 live 安装介质使用 SquashFS 文件系统，但根据这项变更提案，Fedora 42 所有由 Kiwi 制作的 live 媒体，包括 Fedora KDE Desktop、Fedora Budgie、Fedora Xfce、Fedora COSMIC 等版本，将改为使用 EROFS，同时 Fedora CoreOS 的 live 安装镜像也会采用 EROFS。提案认为 EROFS 相较于 SquashFS 更积极地进行开发，且支持更多现代文件系统特性，能够在未来得到更好的应用。EROFS 自 2019 年由华为提出以来，已经增加了许多功能和优化，尤其在移动设备、嵌入式系统和容器中得到了广泛应用。需要注意的是，这项变更仅涉及 live 安装镜像，EROFS 会作为只读文件系统使用。此变更提案仍需通过 Fedora 工程与指导委员会（FESCo）的投票批准。
小石： 为了现代化，我相信大部分人都会毫不犹豫的支持这一变化。

英特尔 THC 驱动程序即将提交 Linux 6.14

Intel THC 驱动程序将为现代 Intel 笔记本的触摸输入设备提供支持，帮助 Linux 操作系统更好地兼容这些设备。该驱动程序将包含在即将发布的 Linux 6.14 内核版本中，支持最新的和即将发布的 Intel SoC。

小石：该驱动的工作从去年就开始了，看来我们有望在新的英特尔笔记本上完美运行Linux发行版。

NVMe PCI 端点功能目标驱动程序将在 Linux 6.14 中推出

来源：Michael Larabel

由西部数据编写的 NVMe PCI 端点功能目标代码是即将在 Linux 6.14 内核中首发的一款有趣的新驱动程序。
在 Linux 6.14 合并窗口打开之前，Linux 块子系统的 “for-next ”分支就已经在排队了，它是使用 PCI 端点框架的新 NVMe PCI 目标驱动程序。有了能在端点模式下运行的 PCI 控制器，就能创建 PCIe NVMe 控制器。
文档补丁详细介绍了该 NVMe 目标驱动程序的所有有趣技术细节。该驱动程序主要用于测试目的，例如在拥有 PCIe 端点控制器的小型单板计算机上创建一个 NVMe 目标来循环文件或块设备。也可以使用 TCP 目标来连接远程 NVMe 设备。
实践中 Rock5B 板（搭载 Rockchip RK3588 SoC 和 PCI Gen3x4 endpoint 控制器）进行测试时，使用 fio 工具进行随机 4K 读取时，最大性能为 131 KIOPS，并且最大吞吐量可达到 2.8 GB/s。
除非出现任何最后一刻的问题，该驱动程序应该在即将到来的 Linux 6.14 内核周期中首次亮相。

小石：虽然没什么关系，但是这个驱动程序还是让我想起来某些伪装成M.2 NVMe的DMA硬件....也许是我最近FPS游戏玩多了吧。

开源虚拟化 API libvirt 11.0 发布

来源：Michael Larabel
Libvirt 11.0 发布了多个重要新特性和改进，增强了其作为开源虚拟化 API 的功能。主要新增了对 vLAN 的支持，使得用户可以在标准 Linux 主机桥接器上进行 vLAN 标记和中继配置。此外，引入了对直接和扩展 TLB Flush 特性的支持，改善了内存管理，并扩展到 Microsoft Hyper-V 平台。该版本还允许用户在虚拟机的 domain XML 中自定义设备别名，增加了 VirtIOFS 的只读模式，优化了 QEMU 迁移功能，并修复了一些已知问题，进一步提高了性能和稳定性。

小石：这些新功能对喜欢折腾All in ~BOOM~ One的高级玩家有重要意义，有了Vlan支持也许某些东西没必要跑在Docker里了，LXC不失为另一轻量化的选择。