我承认我偷懒了，两年前4.2寸墨水屏电子价签改造记录——持续更新 这篇文章当初放了大家鸽子。
作为弥补，我抽空选了这几天晚上带凌晨，把原先可用的代码里的主要内容（寄存器数据等）喂给了DS，然后开始VibeCoding疯狂Debug，总算出了一版能用的。
主要适用于BLOZI 的4.2inch 红白黑三色电子价签，曾经该公司尿崩的时候在淘宝/咸鱼有较大规模流出，当时不做完整一是确实没资料无法彻底整明白，二是整明白了发出来除了让奸商涨价没什么屌用。
这个时间点，货早就出完了，这个规格的价签估计也早就停产换代了，发出来供手上还有留存的垃圾佬娱乐。
仓库地址：epd4in2_dev — ESP8266 驱动 4.2 英寸 三色墨水屏（400×300）
你可能已经发现我的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可能潜在的混乱和污染问题，这个仓库的更新我不会推送到原始仓库，就让本项目作为我的个人试验品好了
具体更新如下：
SOCKS5/HTTP 代理支持
CURLPROXY_SOCKS5_HOSTNAME），避免 DNS 污染HTTP 请求统一重构
Utils/Http.phppostForm() 方法，统一处理 Mastodon/GoToSocial 的表单编码 POST 请求Utils/Proxy.php 集中管理，一处配置全局生效增强 HTTP 层错误日志
FediverseSync/
├── Utils/
│ ├── Proxy.php # 增强：支持 SOCKS5+HTTP 代理类型选择
│ └── Http.php # 增强：新增 postForm() + 代理集成 + 日志增强
└── Plugin.php # 新增5个代理配置项留几块老硬盘，偶尔通电可以看到过去的自己在忙碌什么。
因为酷Q ，我第一次接触到了Docker和基于Openbox窗口管理器和Wine 的Linux下Windows服务软件运行方案。
我是中国境内较早一批接触并实用AI chat模型的非计科高中生。
那时候腾讯还在ai.qq.com持续测试传统NLP 算法的chat模型，即便效果远不能与现在的LLM相比拟，这些现在可以称为古董的早期产品还是给当时的我还有其他朋友带来了极大的震撼。
那年，眺望世界已经不能依靠原版shadowsocks实现，新的替代者是Trojan
那年，Discuz是境内主流论坛服务软件。
那年，Python有了一个国产IDE NovalIDE。
那年，SSH 还是XShell Plus的天下。
那年，PanDownload 和无私分享的cookies拯救无数被百度云盘困住的用户。
那年，PCL替代不掉难忘的旋律
那年，联机侠跨越时空提前挤占了网易的用户空间
那年，我第一次玩孤岛危机2 大型开放世界FPS游戏。
那年，第一次体验COD 4颠覆性游戏制作水平
那年，激活Windows只需要启动AAct 。
那年，酷Q与论坛还在，开发可用易语言。
互联网有记忆，我们也有，缺少的记忆欢迎补全。
Linux内核遵循一切皆文件原则，Flutter开发遵从一切皆组件Widget的原则。应用界面由组件与组件的嵌套堆叠构成，组件按照布局作用有布局组件（如Center，Column）和一般组件（常见Text，MD风格组件：Scaffold，floatingActionButton）
Flutter提供的布局组件命名及其作用与前端CSS样式/Python Tkinter中的布局样式组件类似。
Center 是一个布局 widget。它接收一个子 widget，并将其放置在父 widget 的正中间。
按照状态区分则分为有状态组件 （集成自StatefulWidget）和无状态组件（继承自StatelessWidget ）
有无状态，主要区别在于是否需要在应用运行期间动态改变数据并更新UI。
属于不可变组件，创建后所有的属性、UI 呈现均固定不变。它不依赖任何随时间变化的数据
生命周期：简单，仅包含一个 build() 方法。
性能：性能开销低，不需要管理状态和触发重绘。
常见场景：静态文本（Text）、图标（Icon）、静态图片以及页面头部导航栏（AppBar）
class MyStatelessWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Text('这是一个无状态组件');
}
}特点：可变组件，在生命周期内可以持有、改变状态（State），并在状态改变时自动刷新、重新构建 UI。
组成部分：包含两个类，一个继承自 StatefulWidget，另一个继承自 State。UI 的逻辑和布局写在 State 类的 build 方法中。
状态管理：通过调用 setState() 方法通知 Flutter 框架数据已改变，从而触发 build 重新绘制界面。
常见场景：复选框（Checkbox）、输入框（TextField）、计数器、网络请求加载中状态等需要根据用户交互或数据更新而变化的 UI。
MyStatefulWidget extends StatefulWidget {
@override
_MyStatefulWidgetState createState() => _MyStatefulWidgetState();
}
class _MyStatefulWidgetState extends State<MyStatefulWidget> {
int _counter = 0;
// 函数命名下以划线开头表示该函数是一个私有函数，否则默认为公共
void _incrementCounter() {
setState(() {
_counter++; // 改变计数器数值并触发UI更新
});
}
@override
//重写build方法
Widget build(BuildContext context) {
//返回一个可以检测手势的小部件：GestureDetector
return GestureDetector(
//onTap属性指定接受点击事件时调用私有函数_incrementCounter()
onTap: _incrementCounter,
child: Text('点击次数: $_counter'),
);
}
}在关闭Frp的tcp mux 后上传才正常持续，之前是小文件可以秒传卡100%，大就传一下等待一会儿就报错Network Error（仅使用Frp进行端口转发的情况下）如果再加上Nginx进行反向代理没有写明超时时间，默认60s就更完蛋了，给你报405/502/504等一串错误。
HK 大陆3网直连 200Mbps的VPS做转发，一个30MB的文件1MB分片已经传了十几分钟了，真的逆天啊我很难想想这性能瓶颈到哪里了，哪怕作为下载方的家宽服务器现在也有100Mbps下行，我本地直接5G流量居然还是这么龟速。 纯纯逆天。
折腾这个玩意真的让我力竭了，当然力竭的倒霉蛋也不只我一个，互联网上随手就能搜到类似的问题，而且最终说是解决的实际和没解决也区别不大，依旧是慢如蜗牛。
看个帖子：tcpmux 会大幅降低链路速度#2987
看完你应该大致明白发生了啥，总之开发者们选择了稳定性，但是这在我的应用场景就很糟糕。
所以我最终选择了关闭TCP MUX。
首先，我刚才提过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。
在理想的情况下，QUIC一定是最好的选择，如果网络波动明显只能退选KCP。但是考虑到实践中某些运营商对UDP流量极端的QoS策略，我只能选择TCP和基于TCP的协议。
在某些特殊环境下，开启流量加密是你不得不做的选择，但是如无必要加密和压缩两个都没有必要开，特别是设备cpu性能明显羸弱的情况下，开启流量压缩没有任何意义。
懒人方案：决定24H不睡迎接中秋节——顺便修一修linuxuser.site邮件服务器的严重不可用问题
通过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。）
QUIC 强制 TLS1.3 加密握手开销大，且其默认的拥塞控制算法CUBIC基于丢包设计，一旦检测到丢包会激进地降低发送速率。家宽受运营商跨网和固有机房节点设备性能限制本就处于较高丢包率的网络环境中，CUBIC 会频繁地触发降速机制，导致吞吐量骤降无法像 KCP 那样快速重传，导致转发Cloudreve流量时出现严重的连接超时和假死问题。
具体配置分享如下：
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"
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 = "你的密码"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的固定开支。
所以拉倒吧我还是用原版。
前段时间我去爬山，回来写了文章：朱雀国家森林公园痛苦一日游
上传图片的时候发现当前时代的浏览器并不支持浏览HEIF格式的图片，但是这一标准在苹果和许多较新安卓设备上都已经开始推广，并且压缩率不错，所以能不能想办法让浏览器显示HEIF格式的图片呢？
hoppergee/heic-to Convert HEIC/HEIF images to JPEG, PNG in browser
我的需求显然早就有人在做了，这个项目利用javascript提供了一个在前端将HEIF格式图片转换成jpeg/png的方案。
<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
本文是对计划表中：基于人工+AI的开源与自由软件和科技采集发布，旨在复刻老王叔叔的linux.cn模式 的具体实践。
昨天晚上，我买下了一个新域名：linuxuser.site 寓意：“linux用户站”
为什么是用户/User而不是“粉丝/Fans”或者“玩家”呢？
我认为“用户”一词是最普遍的，最能囊括受众群体的。
同一时间，我在本地部署了“linux用户站”的web服务器，和本博客相同的typecho。也算是一种路径依赖吧，我已经很难接受WP那种臃肿的PHP应用，这次的部署与之前有所不同，我没有使用MySQL/MariaDB而是选择了SQLite。
现在你可以访问https://linuxuser.site 查看这个简陋的站点。
国内有许多人，特别是年轻人对Linux的印象还停留在：黑客之选、极客玩具、普通人用不了、必须用命令行 这样的刻板印象。
除此之外，还有许多人虽然每天在互联网上把Linux挂在嘴边，频繁浏览相关视频，频繁发布相关评论，却从不在实际生产生活中使用Linux内核和各种Linux发行版。这种人在互联网上有一个很贴切的新名词：云玩家
搭建这个站点，既是为了圆我曾经对自由软件和开源的一腔热血，也是为了做点公益，冲淡充斥互联网的低质量口水文章，给希望以及正在使用Linux发行版的朋友们指引方向。
这个站点的建设也与linux.cn停运有着不可割舍的关系，在我看来老王叔叔是一个值得敬佩的Linux传道者，linux中国的文章也一度惠及我和身边的朋友，搭建这个站点亦有复刻Linux中国复活社区的意味。也许不久的将来我们有机会重现一个新的炎黄角马。
目前来看，我完全有能力自己承担域名和服务器的基本运维。甚至有余力时不时发点文章或者科普，在站点规模持续扩大超出作为我的业余爱好的对应资费水平之前，我不打算给服务器添加任何广告。我也不打算把站点打造成一个盈利工具，站点的一切收入会全部投入站点运营本身。如果侥幸有所盈余，就捐给联合国儿童基金会吧。