因为内容相关性较差本文没有发表在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之家、凤凰网科技、观察者网、快科技等

一张图懂得已经看懂了。不懂的，我再多废话几句：
我买的是联想的拯救者，以前也用过ThinkPad。
在我接触过的所有厂商的设备里，联想是唯一一个我装好Fedora/Debian后发现什么驱动都不需要额外安装也能正常用下去的操作系统。
甚至，我在Windows下不想用中国官方特供充斥广告的狗屎图形化驱动软件的时候不得不换了开源替代拯救者工具箱 Lenovo Legion Toolkit
的同一时间，不管是屏幕亮度，键盘背光亮度（Ctrl+Space）还是性能模式切换按键（FN+Q）都已经有完美的快捷键支持。 你能理解Linux下体验先天比Windows更好这件事吗？
买设备回来是为了使用，如果他不好用，那就是💩。
实践证明联想某几条产品线在Linux发行版上体验就是比别家好。
当然，我写这篇文章不是夸联想，目的是告诉你现在Linux发行版使用体验在什么设备上更好。
毕竟，有些东西是从社区长出来的，联想还不配让我拿开源社区无偿劳动的成果给它贴金

留几块老硬盘，偶尔通电可以看到过去的自己在忙碌什么。

因为酷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

按照状态区分则分为有状态组件 （集成自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'),
    );
  }
}

众所周知，境内三大运营商跨网以及境内外Qos问题非常严重，以至于使用Frp时都不得不受限于严重的丢包导致互联网速非常低下。
过去两天的测试发现，QoS不仅影响UDP，甚至TCP也会出现严重的丢包。
具体测试可见：佬友们，中国连不通来了。
这样极端的QoS使得即便用户通过VPN加密数据连接回家也无法获得更好的带宽。

既然本质是QoS的高丢包率导致的，我们就针对性考虑使用更好的拥塞算法以达到预期带宽。
更好的拥塞算法，近期毫无疑问指的是：Brutal 了

Brutal： 这是 Hysteria 自有的拥塞控制算法。与 BBR 不同，Brutal 采用固定速率模型，丢包或 RTT 变化不会降低速度。相反，如果无法达到预定的目标速率，反而会根据计算的丢包率提高发送速率来进行补偿。Brutal 只在你知道（并正确设置了）当前网络的最大速度时才能正常运行。其擅长在拥塞的网络中抢占带宽，因此得名。

BBR 的特性是慢启动和基于 RTT 变化的带宽估算 这一算法具有更好的普适性，因为设计为无须考虑双端带宽值，理论上可以更好的自适应调整到最高带宽。但是在高丢包环境下，BBR就显得有些无能为力了。

使用Brutal的首选自然是Hysteria2了，所以我的最终链路方案就是：
Client —> NAS hy2 Server -> NAS Cloudreve
测试证明这一选项能真正拉满本地上行：我将客户端设置为30Mbps UP后Hy2可以轻松的把向NAS的上传速率拉到30Mbps。

也就是说，使用Hy2 Brutal模式下可以真正把NAS的下行带宽充分利用，必经大部分时候客户端上行也不会超过NAS下行的100Mbps

数据说话

Shadowsocks-libre 直连回家的测试：

Hysteria2 Brutal算法直连回家测试 ：

这真的是爆杀了。
为了方便对比，下面是同客户端本地测试

2026-05-14

这很奇怪，因为我发现在我利用Hysteria2 猛跑了十几GB后整体网络情况（裸连）极大的好转了，连Frp转发在原有参数下速度都恢复了理想水平。我在上述测试之前已经重启了路由器和NAS，所以这种好转看上去和设备重启没有任何关系，唯一有关系的只是凌晨这个特殊的时间点和Hy2的使用。

在关闭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连接复用并继续增大连接池数量到适宜水平。

开机F2 临时断电再拆了后盖把TiPlus 7100 装上关掉安全启动，先切换到显卡混合输出不然刚从3060换过来不然驱动必定水土不服花屏。
进Fedora后dnf reinstall akmod-nvidia xorg-x11-drv-nvidia-cuda然后再dnf update.
还得去改一下/etc/grub.d/里的自定义启动项配置避免硬盘识别顺序不符合预期造成无法正常引导。
依旧可以参考：解决Fedora41 Grub2 无法通过os-prober自动添加Windows启动项的问题 这次比较好的是os-prober识别到新机硬盘的Windows11了。
修改后重新sudo grub2-mkconfig -o /boot/grub2/grub.cfg
切到Windows11后上机先卸载联想辣鸡全家桶，留个Legion Zone即可。不值得探讨
9k啊，但愿尸体机拆散卖配件挂鱼能回点血。

有趣的是，我发现Fedora下y7000p这个电源键灯色和KDE 桌面环境里的性能选项是同步对照的，内核对此显然有一定适配。
然后我就想起来这个有点眼熟的项目：johnfanv2/LenovoLegionLinux 我之前用鸡哥的时候找开源替代就曾误打误撞找到过这个同类项目，没想到我也有用得到的时候。

后续

在备份原厂Windows11 镜像的时候发现原厂安装了一堆AI向的辣鸡软件，毫无例外的哪怕是本地运行的也需要登录。Dism++ 备份出来的67.6GB wim镜像里面估计不少是屎，但是当时没空单独处理了。 上传到阿里云盘进行云备份的时候发现上行很快6~8MB/s，下行只有200~1000KBps，这就我们抽象的广电卡，下载被QOS成屎，上行反而没人管。 如果短时间内大量传输，基站还会把广电从5G踢回4G，过几分钟又恢复5G。

时隔多年，我这台二手蛟龙5 76s终于炸鸡了。
前几天更新过驱动后，昨晚高负载打逃离塔克夫没注意打开游戏模式，然后直接弹出经典提示快速转到无限重启，随后经过数个小时的多次尝试确认设备可能因为CPU过热虚焊导致无法开机。
鉴于自己没有BGA焊台这些专业设备，这台二手鸡哥算是半步管材了，不过用了这么久也勉强算得上寿终正寝。
在Linux.do问了问佬友们意见，再让DS结合互联网评价的各待选热门款笔记本通病最终选择了联想的Y7000P。（没错这违背了我不买联想的原有计划。）
综合价格因素去淘宝一个非官方店铺9000软妹币下单了99新的Y7000P 2025 32G+1TB 的版本。

为啥打破预期买联想

坦白来说我本来首先考虑了机械革命的极光X和蛟龙16Pro，但是这俩通病太严重。高负载积热蓝屏+黑屏重启的问题这俩高概率中奖，还有设计散热垫厚度有问题导致过热USB断连的，扬声器杂音。
至于隔壁华硕天选也不遑多让天选Air 2025查到有键盘漏电问题，给人电麻了还没好好处理。天选6Pro 更逆天C壳鼓包+充电口松动+屏幕闪屏。
直接排除黑屏精灵及HP全系产品后，再看看隔壁戴尔，也是没逃过频繁蓝/黑屏，还有出现键盘失灵。
那么最后我选的Y7000P呢？它也不是一点问题没有，相反问题更恶心。R7000P我没敢买，怕积热重蹈覆辙，Y7000P 2025用上了14代酷睿，这代缩缸问题无需多言。
我敢选是因为现在是2026年，英特尔已经发了微码更新并且老奶奶过马路的联想也终于是在一片骂声里把微码更新慢慢同步上去了。
😂2026年买个好用的笔记本电脑这么难，我真的是没想到。
经济下行，产品质量也下行了，又或许只是以前就烂但是我不知道？