各位Cder好，我是长期混迹在金融系统开发前线的一名后端工程师。最近在帮业务线排查一个网络IO问题时，我发现了一个非常有意思的现象：每逢法定长假，我们接入的A股实时行情服务就会大量爆出超时日志，甚至引发上游服务的雪崩。经过深入的源码级排查，我意识到这不仅仅是简单的网络问题，而是业务场景与网络协议之间的碰撞。今天就来和大家硬核分享一下。

实时金融数据流的严酷要求

在我们这套架构里，我们需要通过WebSocket建立长连接，以极低的延迟接收股票的实时Tick信息。这对于需要进行实时计算的服务来说是刚需。但大家都知道，A股的运行时间是由各种法定节假日和调休决定的。这就意味着，我们的长连接在某些特定的日子里，会面临比平日里更早结束或者更晚开始的数据流阻断。

撕开网络底层的痛点表象

当我们用技术视角去透视这个问题时，节假日前后的异常其实可以归结为以下几个技术痛点：

1. 连接的“假活”状态：A股节前提前休市后，服务端不再下发业务数据包。由于缺乏业务层的交互，如果客户端没有实现完善的应用层心跳（Ping/Pong），TCP连接很容易被沿途的路由器NAT表老化剔除，导致连接名存实亡。
2. 重连风暴（Thundering Herd）：节后开市的瞬间，如果大量断开的客户端同时发起重连请求，极易压垮行情源的网关，造成大面积的503错误。
3. 数据反序列化地雷：由于休市期间数据管道可能会被用来做测试或重置，节后收到的首个JSON payload结构体可能发生变化，导致程序内抛出空指针或解析异常。

优秀的API是如何做产品隔离的？

要解决这些痛点，除了客户端要做防御外，服务端API的设计也至关重要。我查阅了多款行情API的官方文档，发现高标准的接口服务在休市状态机的处理上有一套成熟的逻辑。例如之前接入的AllTick API，在其服务端就实现了优雅的降级策略。在节后重启数据流时，它不会一上来就猛灌实时数据，而是先推送一个经过特殊标记的静态历史快照，用于验证连接质量并同步客户端状态，之后才开始稳定分发流式Tick。

来看看底层是怎么建立这套监听机制的：

import websocket
import json

def on_message(ws, message):
    data = json.loads(message)
    print("收到tick数据：", data)

ws = websocket.WebSocketApp(
    "wss://apis.alltick.co/stock/subscribe",
    on_message=on_message
)
ws.run_forever()

工程应用中的最终解决方案

作为工程师，我们绝不能把系统的稳定性寄托在外部接口的完美无缺上。针对节假日造成的断流，我在中间件层做了如下重构：
第一步：基于时间的黑白名单拦截。通过接入开源的交易日历库，精确计算当前是否处于开盘时间。在非交易时段，主动断开WebSocket连接，释放系统句柄资源。
第二步：实现带有退避的重连状态机。利用指数回退（Exponential Backoff）算法处理节后开盘的重连，有效规避惊群效应。
第三步：强类型的数据校验与缓冲。对所有通过WebSocket推过来的文本进行严格的JSON Schema校验。对于节假日异常期可能出现的缺失字段，利用本地的历史Redis缓存进行字段补齐。
搞定这些，你就再也不用在假期结束前一晚，提心吊胆地盯着监控大屏了。

Ubuntu 26.04 LTS (Resolute Raccoon) 正式版发布 - 现代化的企业与开源 Linux

Ubuntu 26.04 LTS (Resolute Raccoon) GA release Apr 2026

请访问原文链接：https://sysin.org/blog/ubuntu-2604/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

Ubuntu 26.04 LTS 正式版发布

2026-04-23，Ubuntu 26.04 LTS 正式版按计划如期发布。

Ubuntu 26.04 LTS 搭载 Linux 内核 7.0 和 GNOME 50 桌面环境，都是两个优雅的整数版本。

以下是笔者对 Ubuntu 26.04 LTS（Resolute Raccoon）发布摘要总结，对比 Ubuntu 24.04 LTS (Noble Numbat) 的更新内容：

桌面环境（Desktop）

• 应用更新：Firefox 更新至 149/150，LibreOffice 24.2 → 25.8，Thunderbird 更新至 140 “Eclipse”，GIMP 2.10 → 3.0。
• GNOME 50：从 46 升级至 50。支持登录后自动启动应用、优化分数缩放以减少模糊、默认等宽字体大小与 UI 字体匹配、默认安装 Sysprof 性能分析工具。
• 默认应用替换： 文档查看器由 Evince 替换为 Papers（基于 GTK4 和 Rust）。图像查看器由 EOG 替换为 Loupe（Rust + Glycin）。终端由 GNOME Terminal 替换为 Ptyxis。视频播放器由 Totem 替换为 Showtime。音视频缩略图生成器由 Totem 缩略图器替换为 gst-thumbnailers（Rust GStreamer + Glycin）。
• 搜索与索引：Tracker Miners 重命名为 LocalSearch（3.8.2 → 3.11），索引特定文件需勾选安装第三方软件或手动安装提取器。
• 显示会话：Ubuntu 桌面会话仅运行在 Wayland 后端（GNOME Shell 不再支持 X.org），X11 应用可通过 XWayland 运行，其他桌面（KDE on X11, Xfce, MATE, i3 等）仍可使用 X.org。Nvidia 显卡现已完全支持 Wayland。
• 软件管理：默认不再包含“Software & Updates”应用（可手动安装）；App Center 改进（支持安装进度、自更新、Snap 消息、管理页直接卸载、触屏滚动、第三方 Deb 安装）；新增 Security Center（支持家目录权限提示实验功能），附带 prompting-clientsnap。
• 电源与性能：Power Profiles Manager 改进 (sysin)，支持新硬件（尤其 AMD）、多优化驱动、电池感知（仅电池时自动提高优化级别）；新增 NTSYNC 驱动，提升 Wine/Proton 上 Windows 游戏性能。
• 安装与镜像：新增通用 ARM64 桌面 ISO（支持 VM、ACPI+EFI、骁龙 WoA 设备，含骁龙 X Elite 初始硬件支持）；改进 BitLocker 保护下的 Windows 双启动体验（支持在旁安装、加密安装等高级选项）。
• 格式与编解码：原生支持 JPEG XL；默认通过 VA-API 为 AMD 和 Intel 用户提供硬件加速视频编解码；安装时可选第三方软件包集更新（含蓝牙 AAC 编解码器）。
• 更新与无障碍：系统更新不再弹窗抢焦点，改为通知+系统托盘图标；安装程序修复了大量屏幕阅读器无障碍问题。
• 遥测：Ubuntu Insights 将取代 Ubuntu Report，提供对非个人识别系统指标的控制，且为选入制（之前同意不会沿用）。

服务器与常见组件

• OpenSSH：9.6p1 → 10.2p1；弃用 SHA1 SSHFP DNS 记录警告、移除弱 DSA 签名算法支持、新增 PerSourcePenalties、默认支持 mlkem768x25519-sha256 后量子密钥交换、新增 invalid-user 匹配选项、sshd.service 别名为 ssh.service、新增 openssh-client-gssapi 和 openssh-server-gssapi 包、不再生成主机 DSA 密钥、服务器自 1:9.6p1-3ubuntu17 起不再读取 ~/.pam_environment。
• 时间同步：Chrony 取代 systemd-timesyncd 作为默认时间守护进程（新安装），支持 NTS（认证加密 NTP），配置片段位于 /etc/chrony/sources.d/ubuntu-ntp-pools.sources。
• ClamAV：更新至 1.4.3，新增 OneNote 附件扫描、UDF 分区提取、HTML CSS 内嵌图像提取、alz/lha(lzh) 归档提取、图像模糊哈希开关、Office 文档 VBA 提取改进、--cache-size 自定义清理文件缓存、systemd.timer 用于 freshclam、大文件限制处理改进、私有 Freshclam 镜像客户端证书认证、病毒数据库最小年龄等。
• Django：4.2 → 5.2 LTS。
• PHP：更新至 8.5，包含属性钩子、非对称可见性、更新 DOM API、新 URI 扩展、管道运算符、Clone With、#[\NoDiscard] 属性、常量表达式中的闭包和一等可调用对象、持久 cURL 共享句柄、array_first() 和 array_last() 等。
• Dovecot：更新至 2.4.2（配置格式有重大变更）。
• Postfix：默认不再以 chroot 安装，且仅有有限的 chroot 支持。
• RabbitMQ：无法直接升级 (sysin)，需手动步骤（因特性标志）。
• Samba：更新至 4.23 版本，默认启用 SMB3 Unix 扩展、禁用 NetBIOS，并包含大量 AD/DC 相关改进、功能移除及包结构变化，升级前需注意 AD DC 组件与 i386 支持情况。。
• Squid：6 → 7.2；新增 tls_key_log、key-extras、doh_query、cache_peer tls-client-cert-switch；移除 client_delay_access、ftp_epsv、cache_peer no-netdb-exchange、client_persistent_connections、server_persistent_connections。
• SSSD：2.12 版本，现以 sssd 用户（而非 root）运行，需确保其可访问密钥等。
• strace：支持彩色输出（--color、STRACE_COLORS、NO_COLOR）。
• HAProxy：更新至 3.2 LTS；有破坏性变更（如 Runtime API 多命令检测、dynamic server 拒绝 enabled 关键字、非标准 URI 更严格解析、tune.ssl.ocsp-update 重命名为 tune.ocsp-update）。
• DocumentDB：新增，0.108-0 版本（基于 PostgreSQL 的 MongoDB 兼容文档数据库）。
• MySQL：8.0 → 8.4 LTS（8.4.8），移除 32 位 Server 支持（仍提供 armhf/i386 的客户端和客户端库）。
• MySQL Shell：8.0 → 8.4。
• PostgreSQL：更新至 18（新 I/O 子系统、虚拟生成列、uuidv7()、OAuth 2.0 认证等）。
• Valkey：更新至 9.0.3（原子槽迁移、哈希字段过期等）。
• 容器栈：containerd 和 runc 采用定期最新或稳定更新策略。
• 高可用与集群：kpartx-boot 包停用（功能并入 kpartx）；dmraid 包移除（建议用 mdadm 替代）；Pacemaker 更新至 3。

开发工具链

• GCC 14 → 15.2，binutils 2.42 → 2.45，glibc 2.39 → 2.42。
• Python 3.12 → 3.13.9（3.14 也可用）。
• LLVM 18 → 21。
• Rust 1.75 → 1.93（1.91、1.92 也可用）。
• Golang 1.22 → 1.25。
• Zig 新增，默认 0.14.1。
• OpenJDK 21 → 25（LTS 8/11/17/21 仍可用，含 26、27 preview），其中 OpenJDK 25 在 AMD64/ARM64/s390x/PPC64EL 上 TCK 认证。
• Spring® snaps：Gradle 和 Maven 插件可用于构建 Java 应用 ROCK 镜像。
• GraalVM snap：支持 JDK 21/24/25。
• .NET 8 → 10（并扩展至 IBM Power 平台），且有新版 .NET Snap。
• PowerShell snap：扩展至 arm64、s390x、ppc64el 架构。

企业相关

• authd（云认证）更新：EntraID 提供器修复与改进、新增 Google 提供器、支持 EntraID 设备注册、新增 authctl 命令行工具、UID/GID 处理等修复。
• ADSys：Active Directory Group Policy 客户端支持最新 Polkit，改进证书注册。

安全

• AppArmor：新增多个应用沙盒配置文件（可能需报 bug 调整）。
• TPM 全盘加密：支持密码短语管理与恢复密钥再生、更好固件更新集成。
• OpenSSL：支持 QUIC、后量子密码算法（ML-KEM、ML-DSA、SLH-DSA）、更广 EVP 覆盖及性能改进。
• cargo-auditable：Launchpad 上构建的 Rust 包可选启用，二进制内嵌入依赖元数据供漏洞排查。

硬件支持

• NVIDIA Dynamic Boost：在支持的 N 卡笔记本上默认启用（仅通电且 GPU 负载足够时生效，电池不生效）。
• Intel 显卡：支持 Core™ Ultra Xe2 集成 Arc™、Arc™ B580/B570 Battlemage 独立 GPU；Blender 等光线追踪性能提升；Battlemage 上 AVC/JPEG/HEVC/AV1 硬件加速编码；Intel® Compute Runtime 新 CCS 优化；调试支持；oneAPI Level Zero Ray Tracing 提升 AI/ML（Embree on SYCL）。
• Nvidia 挂起恢复：专有驱动中启用 suspend-resume 以防唤醒时损坏和冻结。
• ARM64 桌面平台：linux-generic 内核提供更广 UEFI 启动兼容 (sysin)。
• Raspberry Pi：新启动分区布局（测试新启动资源再提交，要求固件较新）；Pi 桌面镜像改为基于 desktop-minimal 种子（默认应用更少，列出移除清单并可手动清理）；swap 由 cloud-init 处理；RISC-V 仅支持 RVA23S64 ISA（无硬件时仅 QEMU -cpu rva23s64）。
• IBM Z：最低要求 z15（不支持 z14/LinuxONE II 及更旧），z15 及更新性能提升。

通用/底层变化

• sudo-rs：成为默认 sudo 提供器；原 sudo 重命名为 sudo.ws；sudo-ldap 包移除（建议用 PAM 做 LDAP 认证）。
• rust-coreutils：操作系统核心工具（如 base64 等）默认由该包提供（性能提升），同时仍提供经典 GNU coreutils 并可切换。
• Linux 内核：6.8 → 7.0；新增 sched_ext（eBPF 调度策略）、linux-lowlatency 包退休（改用 linux-generic + lowlatency-kernel 调 GRUB）。
• systemd 255 → 259：26.04 是最后支持 System V 服务脚本兼容的版本；默认使用上游 tmp.mount 单元（/tmp 现为 tmpfs）。
• Netplan 1.0 → 1.2：自定义 systemd-networkd-wait-online 逻辑、SR-IOV embedded-switch-mode 改进、解析器跳过损坏配置、ProtonVPN/Azure Linux 修复、wpa-psk-sha256 WiFi、NetworkManager 后端 routing-policy、非标准 OVS 设置支持。
• APT 2.7 → 3.1：新依赖求解器、TLS/哈希从 GnuTLS/gcrypt 切换到 OpenSSL、apt(8) 增加自动分页器、apt-key 移除（直接用 gpgv）。
• Dracut：取代 initramfs-tools 作为默认 initramfs 基础设施（仍支持 initramfs-tools 并可切换）。

Ubuntu Desktop 简介

安全、现代，被数百万人使用的操作系统

全球数百万 PC 和笔记本电脑正在使用的第一开源操作系统。

✅ 专业开发者的首选

每次 Ubuntu 发布都会带来最新的应用程序、库和工具链。Ubuntu 是主要 IDE、游戏开发工具和 AI/ML 软件的首要平台。

✅ 满足你日常使用的所有需求

Ubuntu 提供网页浏览、通讯、游戏与内容创作的必备应用，包括 Firefox、Chrome、Discord、Steam 和 OBS Studio，满足你日常计算的所有需求。

✅ 为隐私与安全而设计

通过定期更新和内置安全功能，Ubuntu 优先保护用户隐私与系统完整性，是注重数据安全用户的可靠之选。

✅ 深度集成企业工具

Ubuntu 无缝集成企业环境。通过 Ubuntu Pro 订阅，你可以获得运行 Ubuntu 于高安全环境所需的所有工具：安全修补、设备管理等。任何人都可以免费在最多 5 台设备上使用 Ubuntu Pro，企业用户可免费试用 30 天。

✅ 完全开源

Ubuntu 始终免费供下载、使用与分享。我们相信开源的力量；如果没有全球志愿开发者社区，就不会有 Ubuntu。

Ubuntu Server 简介

借助 Ubuntu Server 实现横向扩展

Ubuntu Server 为企业数据中心（无论是公有云还是私有云）提供经济性与技术性的可扩展能力。无论你是要部署 OpenStack 云、Kubernetes 集群，还是一个拥有 50,000 个节点的渲染农场，Ubuntu Server 都能提供业界领先的高性价比横向扩展性能。

✅ 性能与多功能性

Ubuntu Server 获得领先硬件厂商（OEM）认证，提供精简的初始部署，并包含集成的部署与应用建模工具，因此你可以最大化利用基础设施资源——无论你在部署 NoSQL 数据库、Web 集群，还是云环境 (sysin)。

✅ 可靠的发布周期

Ubuntu Server 的长期支持（LTS）版本默认为 Ubuntu Main 软件仓库中约 2,500 个软件包提供五年的标准安全更新。每六个月发布一次的中期版本带来新功能，而硬件支持更新则为所有受支持的 LTS 版本提供最新机器的兼容支持。

✅ 最广泛使用且值得信赖的平台

根据 OpenLogic 2025 开源生态支持报告，Ubuntu 是私有云实施的基础，也是全球使用最多的 Linux 发行版（连续第三年位居第一）。

下载地址

Ubuntu 26.04 LTS (Resolute Raccoon) GA, 2026-04-23

• Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit PC (AMD64 x86_64) desktop image
• Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit PC (ARMv8 AArch64) desktop image
• Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit PC (AMD64 x86_64) server install image
• Ubuntu 26.04 LTS (Resolute Raccoon) 64-bit ARM (ARMv8 AArch64) server install image
• 请访问：https://sysin.org/blog/ubuntu-2604/

虚拟机模板下载：

• Ubuntu 26.04 LTS x86_64 OVF (sysin) - VMware 虚拟机模板

更多：Linux 产品链接汇总

背景

最近写项目发现了一个有意思的报错。我发现它让人摸不到头脑，甚至每次写到新增登录方式必然会报一次错。

报错截图

可以看到是由于懒加载，导致的无法处理代理对象。

问题代码复现

验证过滤器拿认证用的方法代码：

   @Override
    @Transactional
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        if (username.length() == 28) {
            return this.loadByWechatOpenid(username);
        } else {
            // 学生登录
            Optional<User> userOfStudent = this.loadBySno(username);
            if (userOfStudent.isPresent()) {
                return userOfStudent.get();
            }

            // 正常登录方式
            User user = this.userRepository.findByPhone(username).orElseThrow(() -> new UsernameNotFoundException("e"));
            user.getAuthorities();
            return user;
        }
    }

     /**
     * 学号登录
     * */
    private Optional<User> loadBySno(String sno) {
        Optional<Student> studentOptional = this.studentRepository.findBySnoAndDeletedFalse(sno);
        if (studentOptional.isPresent()) {
            Student student = studentOptional.get();
            if (student.getUser() == null) {
                User user = this.saveByStudent(student.getName(), student.getSno());
                student.setUser(user);
                this.studentRepository.save(student);
                return Optional.of(user);
            }
            return Optional.of(student.getUser());
        }
        return Optional.empty();
    }

报错方法代码：

@Entity
@Data
public class User {
 
    ...

    // 默认是懒加载
    @ApiModelProperty("角色")
    @ManyToMany
    @JsonView(RolesJsonView.class)
    private Set<Role> roles = new HashSet<>();

    ...

    @JsonView(AuthoritiesJsonView.class)
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        if (null == this.authorities) {
            Set<String> authorities = new HashSet<>();
            // 这行报错
            if (null != this.getRoles() && !this.getRoles().isEmpty()) {
                authorities = RoleServiceImpl.getGrantedAuthorities(this.getRoles());
            }
            this.authorities = authorities.stream().map(authority -> (GrantedAuthority) () -> authority)
                    .collect(Collectors.toSet());
        }
        return this.authorities;
    }
}

解决方案

这里先告诉一下解决方案，先在方法上添加@Transactional，在从数据库拿到user时，在方法结束前调用user.getAuthorities()。其实这里调用user.getRoles()是一样可以的。

 private Optional<User> loadBySno(String sno) {
        Optional<Student> studentOptional = this.studentRepository.findBySnoAndDeletedFalse(sno);
        if (studentOptional.isPresent()) {
            Student student = studentOptional.get();
            if (student.getUser() == null) {
                User user = this.saveByStudent(student.getName(), student.getSno());
                student.setUser(user);
                this.studentRepository.save(student);
                // 在返回user的时候调用一下，getAuthorities()方法即可
                if (user != null) {
                    user.getAuthorities();
                }
                return Optional.of(user);
            }
            if (student.getUser() != null) {
                student.getUser().getAuthorities();
            }
            return Optional.of(student.getUser());
        }
        return Optional.empty();
    }

探究原因

什么是懒加载？实际上就是用了代理模式的方法，减小程序的处理压力。
用一个简单的例子来说：现在有clazz，student和teacher3个实体，他们3个各自有20个属性。在我们日常开发中，对于一个实体并不会把它所有的属性都使用上，相反，而是使用几个属性。那这对服务器来说不久加载了一堆没用的信息吗，我内存就那么大。Spring Boot说：有了我用代理模式不就好了吗。我把@Transactional删除后，它就报错了，实际上这个schedules的类型是List<Schedule>他这里变成PersistentBag类型。它里面没有数据，就报错了。

另一个问题

理解了什么是懒加载，以及如何解决上面的问题之后，下面介绍另一个看起来毫无关联但实际上也与懒加载有关系的问题。可以看到下面的报错也很神奇：状态码是200，却是报错了。

一头雾水的时候，先去看控制台->网络。发现了一个有趣的问题，数据太长了，数据可能被截断了，浏览器觉得不是json数据。实际上是实体对象互相嵌套导致的，schedule中有course，course中有courseItem，courseItem中有schedule...然后就导致了这个问题。

解决方案

在courseItem中的schedule属性加上jsonView。这样可以控制controller返回数据时返回实体的数据，这里不细讲。

@Setter
@Getter
@Entity
public class CourseItem extends BaseEntity{
    ...

    @ManyToOne(fetch = FetchType.LAZY)
    @JsonView(ScheduleJsonView.class)    // 加上这行
    @ApiModelProperty("课程计划")
    private Schedule schedule;

    public interface ScheduleJsonView {}
    ...
}

@RestController
@RequestMapping("schedule")
public class ScheduleController {
   ...
   @GetMapping("getAllByCurrentTermAndCurrentUser")
    @JsonView(GetAllByCurrentTermAndCurrentUserJsonView.class)
    public List<Schedule> getAllByCurrentTermAndCurrentUser() {
        Term term = this.termService.getCurrentTerm();
        if (term == null) {
            return List.of();
        }
        return this.scheduleService.getAllByCurrentTermAndCurrentUser(term);
    }

    private interface GetAllByCurrentTermAndCurrentUserJsonView extends
            Schedule.CourseJsonView,
            Schedule.ClazzJsonView,
            Schedule.Teacher2JsonView,
            Schedule.Teacher1JsonView,
            Course.CourseItemJsonView,    
            GetSchedulesInCurrentTermJsonView {
    }

    ...
}

有趣的思考

两个报错看起来感觉都没什么关联，为什么放到一起。想想我们刚刚讲的懒加载，对于一个实体，加上了@OneToMany等的属性，他是不能拿到值的，我们得在一个加了@Transactional的方法结束前get一下才能显示。上面的代码很明显，就从数据库中拿了数据，按道理不会显示这些关联实体属性（如courseItem）。

遗漏报错信息

其实在最开始关于懒加载的报错最后有一个no session的信息。这个session和HTTP session是一个东西吗？显然不是的。用一个生动的例子讲一下这个session是什么，有什么作用，会做什么。

懒加载问题继续探讨

把 User（用户）想象成一份档案，而 User 拥有的 roles（角色/权限）是贴在这份档案上的标签。

延迟加载（Lazy Loading）
Hibernate 为了省事，在从数据库取出 User 档案时，故意没有立刻把标签（roles）也取出来，而是贴了一张写着“需要时再去拿”的便利贴。这张便利贴就是一个代理对象。

Session（会话）是负责取资料的人
在 Hibernate 里，真正能从数据库里帮你把数据拿出来的那个“办事员”，就是 session。他只在“数据库操作期间”上班。

懒加载问题发生的瞬间
在业务代码（认证逻辑）里：
先从数据库通过 session 拿到了 User 档案，此时标签还没取，只有便利贴。
数据库操作很快结束了，Spring 自动把 session 关闭了，办事员下班走了。
接着，Spring Security 要检查这个用户的权限，就调用了 user.getAuthorities()，实际上就是想看看便利贴上对应的标签到底写的是什么。

这时候，程序试图通过便利贴去找办事员（session）去数据库里真正取标签，但办事员已经下班（session 已关闭），没办法取了。于是它就报错：

LazyInitializationException: could not initialize proxy - no session
（延迟加载初始化失败 —— 因为没找到会话）

简单说就是：要用的数据在需要被真正读取的时候，负责取数据的“连接”已经断开了。

请求实体过长导致的问题

那么在返回请求的时候开启了session？是的。
Spring Boot 默认配置 spring.jpa.open-in-view=true ，它的作用就是：把 Hibernate 的 session 从你查询数据库一直活到 HTTP 响应写完为止。

时间线是这样的：

请求到达：DispatcherServlet（Spring MVC 核心）开始处理这个请求，OSIV 拦截器立刻为当前线程绑定一个 Hibernate session。

进入控制器方法：你通过 professorRepository.findById(id) 去查教授。这条 SQL 只查了教授表，学生列表并没有被查出来。返回的 Professor 对象里，students 其实是一个“代理对象”（便利贴），正等着有人来真正读取它。

方法返回：控制器返回 Professor 对象。Spring MVC 发现你要输出 JSON（因为 @RestController），于是开始对这个对象进行序列化，为的是生成字符串发给前端。

序列化过程触发了读取：Spring 用 Jackson 把 Professor 转成字符串时，会通过 getter 方法读它的每一个属性。当读到 getStudents() 时，触发了代理对象。Hibernate 发现这个代理需要初始化，于是去数据库执行 SQL 把学生列表查出来。

session 还活着，查询成功：此时 OSIV 绑定的那个 session 还没有关闭，所以 Hibernate 能够顺利执行 SQL，返回完整的学生列表。于是 Jackson 拿到了完整的集合，最终生成的 JSON 里就包含了教授和他的学生。

响应写完后：HTTP 响应完全返回给前端，Spring MVC 工作结束，OSIV 拦截器关闭 session。

对于session的思考

session那么好用为什么要关掉，一直开着不好吗？

每个 Session 背后都占着一个“物理数据库连接”

数据库连接数非常有限。比如你的数据库配置了最大 50 个并发连接。
如果一个请求处理了 1 秒钟，Session 开了 1 秒，那么 50 个请求同时进来刚好用满。
如果你一直不关 Session，它就一直占着这个连接。请求处理完了，用户慢悠悠看前端页面（持续几分钟），连接就一直被扣着。用不了多久，连接池就会被耗尽，新的请求再也拿不到数据库连接，整个系统瘫痪。
数据库连接是非常宝贵的资源，必须“快借快还”。

内存会爆掉

session 是一个“一级缓存”，它会一直跟踪你加载过的所有对象，并给它们拍快照（用于脏检查）。
一个请求你查了 10 个教授，它记着 10 个对象。
如果不关闭，随着时间累积，这个 session 缓存里的对象会越来越多，历史查过的东西全堆在里面，而且因为被 Session 引用着，GC 也不能回收。
最终就是内存泄漏（OOM）。

数据一致性问题（很严重）

session 有“重复读”的保证：同一个 session 里查同一个 ID 两次，第二次直接给你缓存里的旧对象，根本看不到数据库的最新变化。
如果 session 一直开着，用户张三在 10:00 查了一个教授的薪水是 1 万。
10:05 管理员在其他系统里把薪资改成了 2 万并提交了。
10:10 张三再次在这个一直开着的 Session 里查这个教授，看到的还是 1 万，因为 session 还拿着旧缓存。
一个长期存在的 session，相当于一直活在“事务快照”里，完全无法跟数据库同步。

所以，session 必须设计成“即用即关”的短生命周期。它的职责就是服务好“一次业务操作”或“一次 HTTP 请求”。做完事赶紧关，释放连接、释放内存、下次查询拿到新数据。

总结

1. 对于在Spring Boot的实体中的有@OnToMany等注解的属性，会默认开启懒加载，你不访问这个属性它就不加载出来。
2. 由于我们使用的是Spring Boot过滤器链实现的登录功能，我们需要显示的开启session或者用上文的方法。
3. Spring Boot会启用默认配置 spring.jpa.open-in-view=true， 把 Hibernate 的 session 从你查询数据库一直活到 HTTP 响应写完为止。

4. 用一个JPA中的话说Hibernate中的session就是Entitymanager。

   参考

   Hibernate ORM 用户指南：https://docs.hibernate.org/orm/5.4/userguide/html_single/#pc-...
   JPA配置：https://docs.spring.io/spring-boot/appendix/application-prope...

JDK（Java Development Kit）是Java开发的核心工具包，没有它你就没法编译和运行Java程序。无论你是刚入门的新手，还是经验丰富的开发者，掌握JDK的下载和安装都是第一步。

现在市面上主要有两种JDK：Oracle JDK和OpenJDK：

Oracle JDK是官方版本，功能完整但商业使用需要注意许可证；
OpenJDK是开源版本，完全免费，功能和性能与Oracle JDK基本一致。
对于普通学习者来说，两者都可以。OpenJDK完全免费，Oracle JDK个人学习也免费。

选择JDK版本是个技术活。Java每6个月发布一个新版本，但只有LTS（长期支持）版本适合生产环境。下面这个表格详细对比了各个版本，帮你做出明智选择：

JDK官网下载

JDK官网下载地址：JDK安装包下载（从1.7~26，官网正版）

对于初学者，我建议下载OpenJDK 17，它平衡了稳定性和现代特性。

Java JDK安装

各个版本的 JDK 安装过程 99.9% 都是相同的，接下来我以 JDK17 为例，演示 JDK17 安装和配置的过程。
1）下载JDK 17安装包后，双击运行安装程序：

2）默认安装到 C 盘，这里我将其安装到了其他非系统盘（D:\JDK17\）。注意，安装路径一定要记住，不要搞丢，后面配置需要用到：

3）一直往后走，直到安装完成：

JDK配置环境变量（重要步骤）

1）右键点击"此电脑"或"计算机"，选择"属性"：

2）然后点击"高级系统设置"：

3）在系统属性窗口中，点击"环境变量"按钮。

4）在系统变量部分，找到并选中"Path"变量，点击"编辑"。

5）点击"新建"，添加 JDK 的 bin 目录路径，我的是 "D:\JDK17\bin"。

6）点击"确定"保存所有更改。

7）验证安装是否成功。按组合键 Win+R，输入cmd打开命令提示符（cmd），输入"java -version"和"javac -version"，如果显示JDK 17的版本信息，说明安装和配置成功。

JDK基础使用

安装配置完成后，你可以开始编写和运行第一个Java程序了。下面是一个简单的示例：

1）创建一个文本文件，命名为"HelloWorld.java"。

2）用文本编辑器打开这个文件，输入以下代码：

public class HelloWorld {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

3）保存文件，注意文件名必须与类名一致（HelloWorld.java）。

4）打开命令提示符或终端，切换到文件所在目录。

5）编译Java程序：输入命令"javac HelloWorld.java"。如果编译成功，会生成一个"HelloWorld.class"文件。

6）运行Java程序：输入命令"java HelloWorld"。如果一切正常，你会看到输出"Hello, World!"。

虽然可以用文本编辑器和命令行开发Java程序，但对于实际项目，建议使用专业的集成开发环境（IDE）：

• IntelliJ IDEA：目前最流行的Java IDE，功能强大，社区版免费。
• Eclipse：老牌的Java IDE，完全免费，插件丰富。
• VS Code：轻量级编辑器，通过Java扩展包支持Java开发。
  这些IDE提供了代码自动补全、调试、版本控制、项目管理等功能，可以大大提高开发效率。

JDK常见问题

如果java命令找不到，检查环境变量配置。设置JAVA_HOME和Path后，需要重新打开命令行窗口。

编译时遇到版本错误，检查javac版本。用javac -version查看编译器版本，确保与java版本一致。

系统中有多个JDK时，通过设置JAVA_HOME来指定使用哪个版本。大多数IDE也支持选择不同的JDK。

JDK下载安装教程总结

JDK是Java开发的基石。选择哪个版本和发行版，取决于你的具体需求。对于大多数情况，OpenJDK 17是个安全的选择：它是LTS版本，有长期支持，性能优秀，而且完全免费。

记住几个关键点：生产环境用LTS版本，企业开发优先选OpenJDK，新项目考虑JDK 17或21。正确安装和配置JDK，是你Java开发之旅的第一步，也是最重要的一步。

2026年4月24日，DeepSeek全新系列模型DeepSeek-V4预览版正式上线并同步开源。这是自2025年1月DeepSeek R1发布以来，这家中国AI公司的首个重大版本更新。在长达15个月的等待之后，DeepSeek V4以“百万Token超长上下文、万亿参数MoE架构、全链路国产算力适配”三重重磅升级，宣告了国产大模型正式迈入全球第一梯队。

一、性能突破：多项基准测试对标甚至超越顶尖闭源模型

在业界最受关注的编程能力方面，据泄露的基准测试数据，DeepSeek V4在SWE-bench Verified测试中取得了83.7%的成绩，超越了Claude Opus 4.5的80.9%和GPT-5.2的80%。在数学推理领域，V4在AIME 2026中达到99.4%，IMO Answer Bench中取得88.4%的高分。

在通用知识评测方面，V4在MMLU上达到92.8%，HumanEval编程测试达到90%。尤其值得关注的是，V4的推理速度较前代V3提升了35倍，能耗降低了40%。虽然这些成绩均需等待独立第三方进一步验证，但目前的信号已经足够清晰：一款能够与国际顶尖闭源模型正面竞争的开源大模型，已经到来。

二、百万级上下文：从“辅助工具”到“全能搭档”

DeepSeek V4最显著的升级之一，是上下文窗口从前代的128K一举跃升至100万Token，接近10倍的量级提升。这意味着模型可以一次性处理相当于《三体》三部曲体量的完整文本，无需分段或截断。

百万级上下文不仅是参数表上的数字变化，而是工作方式的根本变革。开发者可以将一整套项目文档、会议记录、产品需求和测试报告一次性输入模型；研究人员可以完整分析长篇论文、实验数据和历史文献；法律从业者则能处理数十万字的卷宗材料而不丢失关键细节。V4同步发布了Pro与Flash两种API版本，用户只需修改model_name参数即可调用，极大降低了长上下文能力的使用门槛。

三、万亿参数架构：每一分钱都花在刀刃上

在模型架构层面，DeepSeek V4采用大规模混合专家（MoE）架构，按大小分为两个版本：完整版总参数量高达1.6万亿，Lite版为2850亿。

在注意力机制方面，V4采用了DSA2方案，融合了此前DeepSeek V3/R1中的DSA机制以及今年初论文提出的NSA稀疏注意力机制。MoE系统启用Mega内核融合方案，每层包含384个专家，每次推理仅激活其中6个。在训练与优化层面，优化器选用Muon，强化学习阶段采用GRPO算法并辅以KL散度校正，最终将预训练上下文从32K扩展至1M。此外，V4还引入Engram条件记忆模块，可将20%—25%的稀疏参数卸载至DRAM，在100万Token长度下的信息召回率达97%。

这种架构设计的精妙之处在于：模型虽然拥有万亿级的庞大“脑容量”，但每次推理只需调用其中一小部分——激活参数约370亿，这使V4的推理成本与V3基本持平。用个通俗的比喻：你身后站着一个庞大的专家团，但每次回答问题的，只是其中最适合的那几位，所以库很大、脑子很厚、出手依然很快。

四、极致性价比：重塑AI算力经济账

定价方面，DeepSeek V4延续了公司一贯的“效率优先”哲学。V4 API标准费率为输入每百万Token 0.30美元、输出每百万Token 0.50美元；缓存命中时输入成本降至每百万Token仅0.03美元，相当于90%的折扣。

对比海外主流模型：GPT-4o的输入价格为每百万Token 2.50美元，输出10美元；Claude Opus 4.5的输出价格更高达15美元。DeepSeek V4的价格仅为OpenAI的约1/20至1/50。一位开发者在生产环境中实测后分享：同样的工作负载，GPT-4o月费约为380美元，Claude Opus 4.5接近720美元，而DeepSeek V4仅18美元。

更具诚意的是，V4还提供夜间低峰时段（北京时间23点至次日7点）的半价优惠，所有Token类型均可享受50%折扣。对于批量处理、离线分析等非实时任务场景，这是实实在在的成本优化。

五、国产算力适配：从“能用”到“好用”的战略跨越

DeepSeek V4此次最受行业关注的决策之一，是在硬件路线上选择了全面拥抱国产芯片。据多方信息显示，DeepSeek V4将运行在华为最新的昇腾芯片上，工程师完成了从英伟达CUDA生态向华为CANN架构的底层代码迁移。这一过程耗费了大量精力用于芯片适配，这也是V4发布时间一再推迟的核心原因之一。

DeepSeek没有向英伟达或AMD提供V4的早期适配权限，而是将早期访问独家开放给了华为昇腾、寒武纪等国产芯片厂商。在昇腾硬件上，V4的算力利用率达到约85%，部署成本仅为英伟达方案的1/3。这意味着V4将成为全球首个不依赖英伟达硬件生态的前沿AI大模型。英伟达CEO黄仁勋在近期采访中也表达了对这一趋势的忧虑，认为一旦顶尖AI模型在国产芯片上跑出竞争力，英伟达多年构建的生态护城河将不再牢固。

当然也需要看到，模型级别的芯片迁移是极其复杂的系统工程。软件层面的差距并不能一蹴而就，CANN框架在算子覆盖、自动并行、内核融合等方面的成熟度仍落后于CUDA生态，这意味着DeepSeek团队需要在大量底层细节上进行针对性优化，甚至手动重写关键算子。这条路虽然艰难，却为中国AI产业开辟了一条全新的可能——软件定义硬件，模型拉动芯片，这或许比任何补贴政策都更有力量。

六、估值飙升与首次融资：市场的信心投票

与V4发布同步，DeepSeek在资本市场也迎来了历史性时刻。据多家媒体报道，腾讯与阿里巴巴正在洽谈投资DeepSeek，公司目标估值从最初的至少100亿美元上调至逾200亿美元。这是DeepSeek成立以来的首次外部融资，标志着创始人梁文锋长期坚守的“不引入外部资金”立场出现重大转变。

从100亿美元到200亿美元的估值跃升，市场需要的不仅是一个好的故事，更需要看得见的技术突破和可持续的竞争力。V4在性能、成本、国产化三个维度的同时发力，正是支撑这一估值的核心逻辑。

结语

回顾DeepSeek的发展历程，从V2让行业意识到国产模型也能把性价比打到位，到V3在多任务上逼近GPT-4水平，再到R1的爆火出圈，这家公司一直在做同一件事：把顶级AI能力从实验室的奖杯，变成开发者人人都用得起的“基础设施”。今天正式上线的DeepSeek V4，标志着国产大模型在性能上真正具备了与国际顶尖模型同台竞技的实力，同时也向全球AI行业展示了一条不同于“堆算力、堆资金”的全新发展路径——这条路径上，效率、开放和自主可控，比单纯的规模更有价值。

本文由mdnice多平台发布

调研显示，74% 的企业 AI 项目以失败告终，不是技术不行，而是 90% 的企业都犯了同一个错：还没对齐战略、没找准场景，就急着买工具、上模型。

买了大模型 API、部署了智能平台，结果要么用不起来沦为摆设，要么成本失控看不到 ROI，最后钱花了、团队累了，业务却没半点提升。

AI 落地从来不是"技术采购"，而是"战略工程"。与其盲目试错，不如先开好这 3 场会——管理层共识会、场景梳理会、启动培训会，把方向、路径、能力全部对齐，再动手部署，成功率直接提升 80%。

一、先开管理层共识会：别让 AI 变成"老板的自嗨"

痛点直击

很多企业 AI 项目死在起点：老板拍板"必须上 AI"，但高管层认知不统一

• 业务端觉得"增加工作量没用"
• 技术端担心"数据跟不上、架构扛不住"
• 财务端质疑"投入大、回报看不见"

最后各怀心思，资源分散，项目还没开始就内耗不断。

管理层没共识，项目还没开始就注定失败。

会议核心目标

统一高层认知、明确 AI 战略定位、锁定资源与预算、划定责任边界，把"要我做 AI"变成"我们一起做 AI"。

会议议程

参会人员：

• 老板/一把手（必须到场）
• 各业务部门负责人
• IT 负责人
• 财务负责人

会议时长： 2-3 小时

1. 现状痛点复盘（45 分钟）

业务端： 列出当前核心痛点

• 报表每周花 2 天整理，还经常出错
• 数据分散在 5 个系统，对不上数
• 重复性工作太多，人手不够
• 决策靠经验，没有数据支撑

技术端： 汇报数据现状

• 数据孤岛情况（哪些系统不互通）
• 数据质量评估（完整性、准确性、一致性）
• IT 架构兼容风险

财务端： 测算行业 AI 投入产出基准

• 可承受预算区间
• 预期 ROI 门槛

2. AI 价值对齐（30 分钟）

不聊技术，只聊业务： AI 能解决哪 3 个核心痛点？带来哪些可量化收益？

✅ 正例：

"BI 驾驶舱让报表效率提升 80%，从 2 天→4 小时"
"AI 客服降低人力成本 50%，响应时长缩短 60%"
"数据治理让口径 100% 统一，决策准确率提升 40%"

❌ 反例：

"打造行业领先 AI 能力"
"实现数字化转型"
"提升智能化水平"

3. 战略与资源决策（45 分钟）

确定 AI 定位： 是效率工具、业务增量，还是战略转型？

锁定：

总预算：___万
周期：___个月
负责人：___
KPI 指标：___（必须可量化）
失败止损线：___

决议输出： 《AI 战略共识书》，全员签字确认

二、再开场景梳理会：别让 AI 变成"技术秀"

痛点直击

企业最常见误区：为 AI 找场景，而不是为场景配 AI。

买完大模型才思考"用在哪"，最后选了高难度、低价值场景（如全流程智能生产、全域用户洞察），结果数据不达标、业务不配合、周期无限拉长，最后项目烂尾。

场景不清，工具买回来也不知道怎么用。

会议核心目标

从真实痛点出发，筛选"高价值、高可行、快见效"的场景，排出优先级，明确落地路径，避免"大而全"的无效投入。

会议议程

参会人员：

• 业务部门负责人（必须到场）
• 一线操作人员（2-3 名，必须到场）
• IT 负责人

会议时长： 3-4 小时

1. 全场景痛点收集（60 分钟）

各部门负责人列出：

最耗时、最重复、最易出错的工作

• 销售报表：手工从 CRM 导出，Excel 整理，每周 2 天
• 库存盘点：人工清点，Excel 记录，每月 3 天
• 客服应答：80% 时间是重复问题，人力浪费
• 合同审核：人工逐条核对，效率低、易遗漏

现有流程最大瓶颈

• 跨部门数据不通，同一数据反复录入
• 审核链条长，一个审批走 1 周
• 人工误差高，每月对账花 3 天

客户/市场最痛需求

• 个性化服务跟不上
• 客户投诉响应慢
• 精准推荐做不到

2. 场景评估筛选（45 分钟）

用"价值 - 可行性"矩阵打分，锁定 P0 优先场景：

推荐优先场景：

3. 场景落地方案（45 分钟）

每个 P0 场景明确：

目标： 可量化 KPI

• "报表效率提升 80%，从 2 天→4 小时"
• "数据准确率提升至 99%"
• "客服人力节省 50%，从 10 人→5 人"

范围： 覆盖哪些业务、哪些部门、多少用户

资源： 需要哪些数据、哪些系统打通、多少人力

输出： 《AI 场景优先级清单 & 落地方案》

三、最后开启动培训会：别让 AI"上线即闲置"

痛点直击

80% 的 AI 系统上线后用不起来，不是技术差，而是人没跟上：

• 一线员工：不会用、不愿用，觉得"增加麻烦"
• 管理者：不懂监控、不会优化，系统出问题不知道怎么解决
• 团队：没有标准流程，各自摸索，最后回归老办法

系统上线≠项目成功，用起来才是成功。

会议核心目标

完成全员认知升级、技能培训、流程落地，建立 AI 使用、监控、迭代机制，确保系统"用起来、用得好、持续产生价值"。

会议议程

参会人员：

• 项目涉及的所有员工（必须到场）
• 业务部门负责人
• IT 支持人员

会议时长： 2-4 小时（含实操）

1. 认知统一（30 分钟）

讲透： AI 不是替代人，而是帮人减负、提效

展示： 优先场景的价值、使用流程、预期效果

消除顾虑：

• 数据安全：权限控制、审计日志
• 操作简便：界面友好、一键操作
• 支持保障：专人支持、快速响应

2. 分层技能培训（60 分钟）

管理层：

• 如何看数据报表
• 如何监控效果
• 如何审批迭代需求

业务骨干：

• 系统操作
• 数据上传
• 问题反馈
• 简单优化

一线员工：

• 基础使用
• 常见问题
• 快捷入口
• 反馈渠道

3. 机制与流程明确（30 分钟）

建立：

• AI 使用规范
• 问题反馈流程
• 迭代优化机制

明确：

负责人：___
考核指标：___
奖励机制：___（鼓励高效使用）

输出： 《AI 系统使用手册》《运营管理规范》

迅易总结：AI 落地的正确顺序，别再搞反了

很多企业的错误顺序：

买工具→上模型→找场景→培训使用→失败烂尾

正确的 AI 落地顺序：

管理层共识→场景精准筛选→全员培训→工具选型→分步部署→持续迭代

AI 不是"买了就能用"的标准化产品，而是适配企业业务、数据、组织的定制化工程。

在你急着采购大模型、AI 平台之前，不妨先对照这 3 场会议，看看自己：

✅ 管理层是否真正达成共识？ ✅ 是否找到了高价值、可落地的场景？ ✅ 团队是否具备使用和运营 AI 的能力？

3 个会议开完，再行动——少走 90% 弯路，少花 80% 冤枉钱。

关于迅易科技

广州迅易科技有限公司，成立于 2007 年，18 年企业级交付经验，服务过 1000+ 成功项目。

我们不推销工具，只提供可落地的 AI 方法论与全流程陪伴——从 3 个会主持、场景方案设计，到端到端交付、持续运维，让企业先验证价值，再大规模投入。

如果您对上述内容感兴趣，欢迎前往迅易科技官网了解。

2026年4月22日，由温州市委、市政府主办的“天下浙商家乡行·走进温州交流座谈会”在温州市人民大会堂隆重举行。浙江省委常委、温州市委书记张振丰，温州市委副书记、市长张文杰，省人民政府驻上海办事处党组书记、主任李雄伟，上海市浙江商会会长、上海均瑶（集团）有限公司董事长王均金等领导与上海市浙江商会企业家代表共聚一堂。拓数派董事长兼CEO冯雷受邀出席会议，并作为金种子企业代表分享了拓数派以“可信Data+零代码智能体AI”深入温州实业，配合国家顶层数据基础设施设计，支持数据节点要素流通。

面对席卷全球的大模型浪潮，冯雷在发言中抛出了一个生动的行业论断：“如果智能体是战斗机，模型是发动机，那么数据就是燃料。” 拓数派敏锐地指出，随着公域高质量公开数据的日益枯竭，未来AI竞争的胜负手（Key）已不在于通用数据的堆砌，而在于如何挖掘、激活和利用那些安全、可信的私有化数据。这正是拓数派坚定不移的技术护城河。

为了攻克AI落地场景的“最后一公里”，拓数派凭借旗舰产品大模型数据计算系统πDataCS，提供坚实的可信“Data+AI”底座，让私域数据与大模型的安全耦合，从五百强大型企业到OPC场景都能零代码构建智能体，实现业务从自动化向智能化的跨越式升级。针对产业集群的复杂需求，拓数派提供专业的、端到端的「Data+AI」解决方案。拓数派致力于助力各行业的“链主企业”构建可信数据空间与数据本体，实现行业智能体AI。

作为杭州“AI十八罗汉”，拓数派与温州近年来结下了深厚合作缘分。自2024年起，拓数派便以技术赋能者的身份深度参与温州的数智化建设，率先助力苍南县成功打造了“社会治理智能体”，为基层治理插上AI的翅膀。随着合作的深入，拓数派在2025年进一步开展了教育实训与“OPC（一人公司）”赋能计划，致力于通过零代码智能体培养新一代超级个体。步入近期，这份合作再度开花结果，拓数派正为苍南县倾力打造的“南哥AI教育平台”提供坚实的底层技术支撑，持续推动地方教育公平与智能化转型。这一系列扎实的落地成果，不仅是拓数派技术实力的缩影，更是对温州持续优化营商环境、拥抱数智经济的最有力回应。

展望未来，作为浙商“金种子企业”，拓数派将继续秉持初心，为温州乃至全国的数字经济高质量发展注入不竭动力。

第十八章 电容式触摸传感器实验

本章将学习ESP32P4搭载的电容 式触摸传感器。利用该传感器，实现电容触摸按键功能。在本章节，通过使用电容触摸传感器通道0（IO2）来做一个简单的电容触摸按键，通过该按键控制LED0的亮灭。
本章分为如下几个小节：
18.1 电容式触摸传感器介绍
18.2 硬件设计
18.3 程序设计
18.4 下载验证

18.1 电容式触摸传感器介绍

18.1.1 触摸按键介绍

在前面按键实验中，我们已经学习过机械按键，这章节我们将学习另外一种人机交互设备：电容触摸按键。
电容式触摸感应技术已经广泛应用在家用电器、消费电子等领域，以此发展的触摸按键产品与传统按键相比下，其主要优势有：
● 无机械装置，不宜磨损老化，使用寿命长；
● 表面无缝隙，无水分、杂质渗透
● 减少元件使用，BOM成本降低
● 面板不用开孔，工业设计成本降低
● 简洁美观，设计灵活
电容触摸按键也可称为电容触摸传感器，主要由保护覆盖层、触摸电极、绝缘基板和走线组成，保护覆盖层位于最上层，绝缘基板上设有电极及走线，如下图所示。

图18.1.1.1 典型触摸传感器系统组成示意图
保护覆盖层：指的是触摸面板。触摸面板必须是绝缘材质，作用是隔离触摸电极与外部环境，起保护作用。但保护覆盖层会降低触摸的灵敏度，需要根据应用场景选择合适厚度、材质。
触摸电极：指的是触摸传感器的重要组成。手指触摸时与触摸电极形成平行板电容器，改变触摸通道的电容量。触摸电极必须是导电材质。样式多变，如PCB板上的铜箔、金属板等。
绝缘基板：对触摸电极起支撑作用，非导电材质。
走线：连接触摸电极与芯片，包括PCB走线和连接器。
触摸传感器电路可以测量触摸通道上的总电容量。电容触摸检测原理主要就是通过测量面板（传感器）和其环境之间的电容变化来检测触摸界面是否有触摸事件发生。当手指触摸传感器表面时，人体的导电性质和大质量构成接地的导电层（平行于触摸电极），该操作构成一个平行板电容器，导致电容量发生变化。当电容量发生改变且变化量超过阈值，会判定为“手指触摸动作”。手指触摸按键场景图如下所示。

图18.1.1.2 手指触摸按键图

18.1.2 ESP32电容式触摸传感器

ESP32-P4内置电容式触摸传感器，通过触摸管脚外接触摸板，构成触摸传感器系统。触摸传感器系统主要应用于人机交互场景中，检测手指触碰或接近。
ESP32-P4提供了多达14个电容式传感器GPIO，如下图所示，能够探测由手指或其他物品直接接触或接近而产生的电容差异。ESP32-P4的触摸传感器同时还支持防水和数字滤波等功能来进一步提高传感器的性能。

图18.1.2.1 触摸通道
接下来，介绍一下触摸传感器的工作原理以及工作信号。首先，来看一下触摸传感器工作原理图，如下图所示。

图18.1.2.2 触摸传感器工作原理
手指触碰或靠近触摸管脚时，管脚电容增大。触摸传感器可检测到触摸管脚上的电容变化。触摸传感器使用固定电源对触摸管脚进行充放电，电压范围为参考高值DREFH~参考低值DREFL。触摸管脚被触摸时，其电容增大，因此充放电时间延长。通过测量触摸管脚在固定周期内充放电所需时间，可判断管脚是否被触碰。
每次电压变化，触摸传感器生成一个脉冲。一个OUT信号包含若干个脉冲。一次测量操作包括：对触摸管脚进行N次（固定次数，可配置）的充放电，然后测量OUT信号生成N个脉冲所需时间。
接下来，通过查看触摸传感器的内容结构，更好了解一下其原理，如下图所示。

图18.1.2.3 触摸传感器内部结构
对触摸传感器的使用，主要就是对FSM进行配置。
FSM设备会释放标准的三角波给引脚电容，相当于给电容进行周期性充放电。FSM控制开始充放电，同时FSM内部的脉冲计数器和时间计数器启动，测量完成N次充放电的任务需要多少us时间。充放电要让电压升到指定阈值才算测量成功，而人手触摸引脚会导致电容增大，充电时间边长。一次测量任务持续时间应小于1ms。
读数的返回结果就是时间值，即耗时多长完成N次充放电。
因此，读出来的raw value越大反映了充电时间越长，人手接触面积越大，读数值越大。官方的其他API给我们配置的就是各种能影响采样时长的参数，比如电压上下限（电容充到多高的电压（DREFH）算是完成充电，放到多低的电压（DREFL）算是完成放电）、斜率控制（充电电流的大小（slope）也能影响采样时间）、采样次数（charge_discharge_times）。

18.2 硬件设计

18.2.1 例程功能

利用ESP32-P4开发板底板的电容触摸按键（右下角白色LOGO，即TPAD），通过电容式触摸传感器对电容触摸按键进行检测，实现对LED0的控制。按下TPAD按键，控制LED0的状态的翻转。

18.2.2 硬件资源

1）LED灯
LED 0 - IO51
2）SENSOR
TOUCH_CH0 - IO2

18.2.3 原理图

本章用到电容式触摸传感器的通道0（IO2）采集TPAD信号，其连接原理图如下图所示。

图18.2.3.1 TPAD连接原理图

18.3 程序设计

18.3.1 TOUCH的IDF驱动

TOUCH外设驱动位于ESP-IDF下的components/esp_driver_touch_sens目录下。使用TOUCH功能，必须先导入以下头文件：

#include "driver/touch_sens.h"

接下来，作者将介绍一些常用的函数，这些函数的描述及其作用如下：
1，初始化触摸传感器函数touch_sensor_new_controller
该函数用于初始化触摸传感器并得到控制器句柄，其函数原型如下：

esp_err_t touch_sensor_new_controller(const touch_sensor_config_t *sens_cfg, touch_sensor_handle_t *ret_sens_handle);

函数形参：

表18.3.1.1 touch_sensor_new_controller函数形参描述
函数返回值：
ESP_OK表示触摸传感器初始化成功。
ESP_ERR_NO_MEM表示内存不足。
ESP_ERR_INVALID_ARG表示错误参数。
ESP_ERR_INVALID_STATE表示触摸传感器已在使用 。
sens_cfg为指向触摸传感器控制器配置结构体指针。接下来，介绍touch_sensor_config_t结构体中各个成员，如下代码所示：

typedef struct {
    uint32_t                        power_on_wait_us;   /* 开机等待时间 */
    float                           meas_interval_us;   /* 每个通道的测量间隔 */
    uint32_t                        max_meas_time_us;   /* 测量一个通道的最大时间 */
    touch_out_mode_t                output_mode;        /* 计数模式的二值化输出 */
    uint32_t                        sample_cfg_num;     /* 采样的样本数 */
    touch_sensor_sample_config_t    *sample_cfg;        /* 数组配置 */
} touch_sensor_config_t;

touch_sensor_config_t结构体用于配置触摸传感器的参数，以下对各个成员做的简单介绍。
1）power_on_wait_us：
通道上电之间的等待时间能够测量，保证数据的稳定性。
2）meas_interval_us：
各通道测量间隔。
3）max_meas_time_us：
测量一个通道的最大时间，如果超过此事件，将触发超时中断。
4）output_mode：
触摸通道计数模式的二值化触摸输出。
5）sample_cfg_num：
用于采样的样例配置号。
6）sample_cfg：样例配置的数组配置。其类型是touch_sensor_sample_config_t，如下所示。

typedef struct {
    uint32_t                        div_num;                /* 触摸输出脉冲分配 */
    uint32_t                        charge_times;           /* 充电盒放电次数 */
    uint8_t                         rc_filter_res;          /* RC滤波器的电阻 */
    uint8_t                         rc_filter_cap;          /* RC滤波器的电容 */
    uint8_t                         low_drv;                /* 低速触摸驱动 */
    uint8_t                         high_drv;               /* 高速触摸驱动 */
    uint8_t                         bias_volt;              /* 内部LDO电压 */
    bool                            bypass_shield_output;    /* 是否旁路屏蔽输出 */
} touch_sensor_sample_config_t;

在文件中有提供一个默认配置宏TOUCH_SENSOR_V3_DEFAULT_SAMPLE_CONFIG进行配置。在文件中有提供一个默认配置宏TOUCH_SENSOR_DEFAULT_BASIC_CONFIG进行配置。
ret_sens_handle是指向触摸传感器控制器句柄结构体的指针，由于参数非常多，且在此也不需要了解他的成员，所以不作展开，想要了解可自行搜索查看。

2，触摸传感器通道配置函数touch_sensor_new_channel
该函数用于配置触摸传感器通道，其函数原型如下：

esp_err_t touch_sensor_new_channel(touch_sensor_handle_t sens_handle, 
int chan_id,
                                   const touch_channel_config_t *chan_cfg,
                                   touch_channel_handle_t *ret_chan_handle);

函数形参：

表18.3.1.2 touch_sensor_new_channel函数形参描述
函数返回值：
ESP_OK表示配置触摸传感器通道成功。
ESP_ERR_NO_MEM表示内存不足。
ESP_ERR_INVALID_ARG表示错误参数。
ESP_ERR_INVALID_STATE表示触摸传感器控制器未使能或已经分配了该通道。
sens_handle为触摸传感器控制器句柄结构体，前面已经有说明了。
chan_id为触摸传感器通道号，可选0~13。
chan_cfg为指向触摸传感器通道配置结构体指针，touch_channel_config_t结构体其定义如下：

typedef struct {
    uint32_t                        active_thresh[TOUCH_SAMPLE_CFG_NUM];  
} touch_channel_config_t;

每个样例配置的激活阈值，当触摸通道平滑值减去基准值超过该阈值时，视为激活。
ret_chan_handle为触摸传感器通道句柄，由于参数非常多，且在此也不需要了解他的成员，所以不作展开，想要了解可自行搜索查看。
3，过滤器配置函数touch_sensor_config_filter
该函数用于配置过滤器，其函数原型如下：

esp_err_t touch_sensor_config_filter(touch_sensor_handle_t sens_handle, const touch_sensor_filter_config_t *filter_cfg);

函数形参：

表18.3.1.3 touch_sensor_config_filter函数形参描述
函数返回值：
ESP_OK表示配置过滤器成功。
ESP_ERR_INVALID_ARG表示触摸传感器控制器句柄为空。
sens_handle为触摸传感器控制器句柄结构体，前面已经有说明了。
filter_cfg为指向触摸传感器过滤器配置结构体指针，touch_sensor_filter_config_t结构体其定义如下：

typedef struct {
    struct {
        touch_benchmark_filter_mode_t   filter_mode;     /* 基准筛选模式 */
        uint32_t                        jitter_step;      /* 抖动滤波步长 */
        int                             denoise_lvl;      /* 噪声水平 */
    } benchmark;                                         /* 基准配置 */
    struct {
        touch_smooth_filter_mode_t      smooth_filter;      /* 平滑数据过滤模式 */
        uint32_t                        active_hysteresis;  /* 迟滞阈值激活 */
        uint32_t                        debounce_cnt;       /* 脱扣计数 */
    } data;                                                 /* 数据配置 */
} touch_sensor_filter_config_t;

4，注册事件回调函数touch_sensor_register_callbacks
该函数用于注册事件回调函数，其函数原型如下：

esp_err_t touch_sensor_register_callbacks(touch_sensor_handle_t sens_handle, 
const touch_event_callbacks_t *callbacks, 
void *user_ctx);

函数形参：

表18.3.1.4 touch_sensor_register函数形参描述
函数返回值：
ESP_OK表示成功。
ESP_ERR_INVALID_ARG表示参数有误。
ESP_ERR_INVALID_STATE表示触摸传感器控制器未使能。
5，使能触摸传感器控制器函数touch_sensor_enable
该函数用于使能触摸传感器控制器，其函数原型如下：

esp_err_t touch_sensor_enable(touch_sensor_handle_t sens_handle);

函数形参：

表18.3.1.5 touch_sensor_enable函数形参描述
函数返回值：
ESP_OK表示成功。
ESP_ERR_INVALID_ARG表示参数有误。
ESP_ERR_INVALID_STATE表示触摸传感器控制器已在使用。
6，启动触摸通道连续扫描函数touch_sensor_start_continuous_scanning
该函数用于对所有已注册的触摸通道进行连续扫描，其函数原型如下：

esp_err_t touch_sensor_start_continuous_scanning(
touch_sensor_handle_t sens_handle);

函数形参：

表18.3.1.6 touch_sensor_start_continuous_scanning函数形参描述
函数返回值：
ESP_OK表示成功。
ESP_ERR_INVALID_ARG表示参数有误。
ESP_ERR_INVALID_STATE表示触摸传感器控制器未使能或已在扫描。
7，触摸通道读数函数touch_channel_read_data
该函数用于读取每个通道不同种类的数据，其函数原型如下：

esp_err_t touch_channel_read_data( touch_channel_handle_t chan_handle, 
touch_chan_data_type_t type, uint32_t *data);

函数形参：

表18.3.1.7 touch_channel_read_data函数形参描述
函数返回值：
ESP_OK表示成功。
ESP_ERR_INVALID_ARG表示参数有误。
channel_handle为触摸传感器通道句柄结构体，前面已经有说明了。
type为读取的数据类型，其数据类型为touch_chan_data_type_t，它是枚举类型，有三个选项：TOUCH_CHAN_DATA_TYPE_SMOOTH、TOUCH_CHAN_DATA_TYPE_BENCHMARK和TOUCH_CHAN_DATA_TYPE_PROXIMITY。

8，启动一次触摸通道扫描函数touch_sensor_trigger_oneshot_scanning
该函数用于启用一次对所有已注册的触摸通道进行扫描，其函数原型如下：

esp_err_t touch_sensor_trigger_oneshot_scanning(touch_sensor_handle_t sens_handle, int timeout_ms);

函数形参：

表18.3.1.8 touch_channel_trigger_onshot_scanning函数形参描述
函数返回值：
ESP_OK表示成功。
ESP_ERR_TIMEOUT表示超时完成一次扫描。
ESP_ERR_INVALID_ARG表示参数有误。
ESP_ERR_INVALID_STATE表示触摸传感器控制器未使能或已在扫描。

18.3.2 程序流程图

图18.3.2.1 电容触摸按键实验程序流程图

18.3.3 程序解析

在08_cap_touchkey例程中，在08_cap_touchkey\components\BSP路径下新建TOUCH_SENS文件夹，并且需要更改CMakeLists.txt内容，以便在其他文件上调用。
1.TOUCH_SENS驱动代码
这里我们只讲解核心代码，详细的源码请大家参考光盘本实验对应源码。TOUCH_SENS驱动源码包括两个文件：touch_sens.c和touch_sens.h。
下面先解析touch_sens.h的程序。对触摸传感器通道、扫描次数以及活动阈值做了相关定义。

#define TOUCH_CHANNEL                   0       /* TOUCH_CHANNEL0 */
#define TOUCH_CHAN_INIT_SCAN_TIMES      3       /* 扫描次数 */
#define TOUCH_ACTIVE_THRESH             1000    /* 活动阈值 */

我们选择使用触摸传感器通道0，扫描次数为3，而活动阈值为1000。
下面我们再解析touch_sens.c的程序，看一下初始化函数touch_sens_init，代码如下：

/**
 * @brief        触摸传感器初始化
 * @param         无
 * @retval         ESP_OK:表示触摸初始化成功
 */
esp_err_t touch_sens_init(void)
{
    /* 采样配置 */
touch_sensor_sample_config_t sample_cfg = 
TOUCH_SENSOR_V3_DEFAULT_SAMPLE_CONFIG(1, 1, 1);   

    /* 控制器配置 */
touch_sensor_config_t sens_cfg = 
TOUCH_SENSOR_DEFAULT_BASIC_CONFIG(1, &sample_cfg); 
    ESP_ERROR_CHECK(touch_sensor_new_controller(&sens_cfg, &s_sens_handle)); 

    /* 滤波器配置 */
touch_sensor_filter_config_t filter_cfg = /* 使用默认过滤器配置提高数据稳定性 */
TOUCH_SENSOR_DEFAULT_FILTER_CONFIG();     
    /* 配置基线值和读数值的滤波策略和更新方式 */
    ESP_ERROR_CHECK(touch_sensor_config_filter(s_sens_handle, &filter_cfg)); 

    /* 触摸传感器通道配置 */
    touch_channel_config_t chan_cfg = {
        .active_thresh = {
            TOUCH_ACTIVE_THRESH,     /* 触摸数值 - 基准值 > 1000，则表示已触摸 */
        },
    };

    ESP_ERROR_CHECK(touch_sensor_new_channel(s_sens_handle, TOUCH_CHANNEL, &chan_cfg, &s_chan_handle));         /* 新建触摸通道 */

    /* 触摸校准 */
    touch_sens_calibration();

    /* 注册触摸传感器回调，这里只取' active '和' deactivate '事件为例 */
    touch_event_callbacks_t callbacks = {
        .on_active              = touch_on_active_callback,     /* 触摸事件回调 */
        .on_inactive            = touch_on_inactive_callback,    /* 释放事件回调 */
        .on_measure_done        = NULL,       /* 测量完成事件回调 */
        .on_scan_done           = NULL,       /* 扫描完成事件回调 */
        .on_timeout             = NULL,       /* 超时事件回调 */
        .on_proximity_meas_done = NULL,       /* 触摸传感器对接近感测完成事件回调 */
    };
ESP_ERROR_CHECK(touch_sensor_register_callbacks(s_sens_handle, &callbacks, 
NULL));      /* 注册事件回调 */

    /* 使能触摸通道 */
    ESP_ERROR_CHECK(touch_sensor_enable(s_sens_handle));

    /* 启动连续扫描 */
    ESP_ERROR_CHECK(touch_sensor_start_continuous_scanning(s_sens_handle));

    return ESP_OK;
}

在触摸传感器初始化函数中，首先通过touch_sensor_new_controller函数使用默认配置创建触摸传感器控制器句柄，然后通过touch_sensor_config_filter函数使用默认配置对过滤器进行设置，后面再通过调用touch_sensor_new_channel函数对触摸通道进行配置。接下来就是触摸校准，注册触摸传感器回调函数以及使能触摸通道。
接下来，介绍一下触摸扫描函数touch_sens_scan，代码如下：

/**
 * @brief          触摸扫描
 * @param        无
 * @retval      true:表示按下;false:表示未按下或已释放
 */
bool touch_sens_scan(void)
{
    bool touch_sens_state = false;  /* 按键状态:未按下 */
    static uint8_t key_up = 1;      /* 不支持连续按 */
    
    /* 读取基准数值 */
ESP_ERROR_CHECK(touch_channel_read_data(s_chan_handle,
                TOUCH_CHAN_DATA_TYPE_BENCHMARK, &benchmark));
    /* 读取触摸数值 */
ESP_ERROR_CHECK(touch_channel_read_data(s_chan_handle, 
TOUCH_CHAN_DATA_TYPE_SMOOTH, &chan_data));

    /* 判断触摸数值 - 基准数值 > 激活阈值 */
if (((chan_data - benchmark) > TOUCH_ACTIVE_THRESH) && 
(touch_cb_state == 0xAA) && key_up)
    {
        touch_sens_state = true;        /* 触摸按键被按下 */
        key_up = 0;
    }
    else if (touch_cb_state == 0x00)    /* 触摸按键已经释放 */
    {
        key_up = 1;
        touch_sens_state = false;
        touch_cb_state = 0xFF;
    }

    return touch_sens_state;
}

在触摸扫描函数中，通过调用touch_channel_read_data函数读取基准数值和触摸数值，后面就判断是否被按下。touch_cb_state变量的值是在回调函数中改变的，0xAA表示在触摸，而0x00表示释放触摸。当按下触摸按键时，该函数返回的是true；当未按下或已经松手触摸按键时，该函数返回的是false。

文件中的其他函数请大家自行查看源码，都有详细的注释。

2.CMakeLists.txt文件
本例程功能实现主要依靠TOUCH_SENS驱动。要在main函数中，成功调用TOUCH_SENS文件中的内容，就得需要修改BSP文件夹下的CMakeLists.txt文件，修改如下：

set(src_dirs
               LED
               TOUCH_SENS)

set(include_dirs
              LED
TOUCH_SENS)

set(requires
               driver
esp_driver_touch_sens)

idf_component_register(    SRC_DIRS ${src_dirs} INCLUDE_DIRS ${include_dirs} REQUIRES ${requires})

component_compile_options(-ffast-math -O3 -Wno-error=format=-Wno-format)

3.main.c驱动代码
在main.c里面编写如下代码。

void app_main(void)
{
    esp_err_t ret;
    bool capkey = false;
    
    ret = nvs_flash_init();     /* 初始化NVS */
    if(ret == ESP_ERR_NVS_NO_FREE_PAGES || ret == ESP_ERR_NVS_NEW_VERSION_FOUND)
    {
        ESP_ERROR_CHECK(nvs_flash_erase());
        ESP_ERROR_CHECK(nvs_flash_init());
    }

    led_init();                 /* LED初始化 */
    touch_sens_init();          /* TOUCH_SENS初始化 */

    while (1)
    {
        capkey = touch_sens_scan();
        
        if (capkey)
        {
            LED0_TOGGLE();
        }

        vTaskDelay(pdMS_TO_TICKS(10));
    }
}

在app_main函数中，调用touch_sens_init函数对触摸传感器初始化后，便在循环中，每隔10毫秒就调用touch_sens_scan函数扫描触摸按键状态，如果被按下，翻转LED0的状态。

18.4 下载验证

程序下载完成后，按下电容触摸按键控制LED0灯的状态。

2026 年 4 月 22 日，全球共享发展行动论坛第三届高级别会议 “数字赋能全球南方高质量发展” 分论坛在北京钓鱼台国宾馆圆满举行。本次分论坛由北京市科学技术委员会、中关村管委会、海淀区人民政府主办，聚焦数字技术赋能全球南方发展、缩小 AI 数字鸿沟。北京智源人工智能研究院（BAAI）与非洲联盟 — 非洲科研创新理事会（AU‑ASRIC）现场签署战略合作备忘录，正式启动中非人工智能人才培养计划，以众智 FlagOS 开放计算技术栈为技术底座，推动 AI 技术、智算资源与人才培养体系向非洲开放，彰显中国科研机构在全球 AI 普惠中的技术担当与创新引领力。

智源研究院理事长黄铁军与 AU‑ASRIC 主席 Beban Sammy Chumbow 签署备忘录，双方将在 AI 人才培养、科研联合攻关、开源技术共享、学术交流等领域开展长期深度合作。此次合作是 AU‑ASRIC 首次与中国机构建立正式战略合作，标志着中非 AI 合作从零散交流迈向机制化、全域化新阶段。智源研究院提供技术培训、AI开放计算平台、课程体系等全流程支持；北京大学赋能课程开发与学术支撑；AU‑ASRIC 负责 52 国区域高校协调与老师邀请，三方协同打造南南人工智能科技合作典范。

本次活动期间，智源研究院相关团队与 AU‑ASRIC 高层代表及非洲 11 国参训教师开展多场深度合作座谈。双方围绕非洲 52 国 AI 人才培养落地细则、FlagOS 开放计算人才教育、远程算力支持、课程体系迭代优化等关键议题充分交换意见，就 2026 年种子教师培育、2028 年规模化扩面、非洲高校 AI 实验室共建等具体目标达成一致。

4 月 15 日，来自非洲 11 国的 AI 教师正式开启在北京为期两周的集中实训，课堂内外涌现出许多温暖生动的瞬间。来自肯尼亚的教师露西此前几乎没有开源算力平台实操经验，面对 FlagOS 操作界面一度有些紧张。智源工程师耐心手把手指导，结合非洲本地智慧农业场景带她完成简易 AI 模型搭建。当她用普通硬件成功跑出运算结果时，激动地与各国教师分享喜悦，并用英语和法语讲解操作心得，现场气氛热烈。

课余时间，老师们主动交流本国 AI 发展痛点：尼日利亚教师穆萨展示乡村教育照片，探讨如何用 FlagOS 搭建低成本 AI 教学实验室；南非教师扎拉分享女性 STEM 教育推广经验。大家互相学习、快速熟悉，原本陌生的跨国教师很快成为志同道合的伙伴。最终，全体参训教师均顺利完成 AI 计算 8 大核心模块学习，不少人结合本国需求设计出本土化 AI 教学方案，为归国授课做好充分准备。

非洲来宾高度认可智源在开放算力与人才培养上的务实支持，期待以本次合作为起点，联合开展大模型应用、智慧农业、智慧医疗等场景创新，共同探索适合非洲发展阶段的 AI 落地路径。非洲科研创新理事会主席 Beban Sammy Chumbow 表示：“我们期待以本次合作为起点，让 AI 真正服务于非洲的粮食安全和公共卫生，也希望这些种子教师回去后，能够运用所学知识培养更多本土人才。”

智源开展中非人工智能人才培养、推广 FlagOS 开放计算相关工作，核心出发点是满足全球南方数字化转型与人工智能能力建设的现实需求，聚焦非洲国家算力短缺、技术门槛高、人才储备不足的核心痛点，依托自身技术与资源优势，搭建合作桥梁，助力缩小数字鸿沟，推动非洲国家实现人工智能领域的自主创新。

其核心价值主要体现在三个维度：一是通过构建开放计算、开源生态与人才共育三位一体的模式，为非洲地区提供切实可行的技术解决方案，破解发展瓶颈，让人工智能技术真正惠及更多国家；二是通过“种子教师”培养、课程共建、远程实训等务实举措，推动教育普惠，夯实非洲国家人工智能人才基础，以人才培养驱动当地产业升级与数字化转型；三是立足中国技术实践，为全球南方国家数字化转型提供可复制、可推广的中国方案与实践路径，彰显开放协作、共享共赢的人工智能国际合作新范式，推动全球 AI 普惠落地，助力构建更加公平、包容的全球数字生态。

当前，人工智能正深刻重塑全球发展格局，但很多国家还普遍面临人才短缺、算力不足、技术壁垒高等现实挑战。非洲拥有 14 亿人口体量的同时，也拥有全球增速最快的年轻群体，但其 AI 专业人才缺乏，数字鸿沟成为制约其发展的关键瓶颈。联合国副秘书长指出，AI 的变革潜力必须惠及世界每一个角落，而非少数特权群体。在此背景下，智源研究院主动承担国际技术交流与科技普惠社会责任，联动非盟官方机构、北京大学等顶尖力量，构建 “技术开放、人才共育、生态共建” 的中非 AI 合作新模式。
作为本次合作的核心技术支撑，以智源研究院为代表的众智 FlagOS 社区成员单位共同打造的 FlagOS 2.0，是全球支持芯片种类最多的开源 AI 系统软件栈，可兼容 18 家芯片厂商、32 款 AI 芯片，实现 ARM、RISC‑V、边缘设备、异构服务器等多元硬件无缝适配，打破专有生态锁定，为算力资源有限的国家提供低成本、高兼容的 AI 运行底座。依托 FlagOS 的统一编译、算子库、并行框架与自动化迁移工具，非洲高校与开发者无需依赖高端硬件，即可开展大模型训练、多模态应用开发等前沿实践，真正实现 “授人以渔” 的技术赋能。

本次中非人工智能人才培养计划采用 “种子教师” 培育模式，构建起 “选拔 — 培训 — 返哺 — 长效支持” 的全链条培育体系。在规模化选拔阶段，项目已吸引非洲 24 国 82 所高校的 131 位教师踊跃申请，最终遴选来自 11 国的优秀 AI 教师来华参训，覆盖非洲五大地理区域，同时兼顾性别均衡与院校代表性，确保培育范围的广泛性与代表性。自 4 月 15 日起，这些非洲教师在北京开展为期两周的集中系统化实训，重点学习 AI 计算 8 大核心模块，同步实操 FlagOS 平台、深度体验中国科创生态，全面提升专业教学与技术应用能力。实训结束后，参训教师将归国开展本土化落地工作，在本校开设 AI 相关课程，智源研究院将持续为其提供教学资源、在线算力及技术支撑，预计单名教师年均可培育 50 名以上非洲本土 AI 学生。在长期化生态建设方面，计划 2026 年首批培育 10 名种子教师，至 2028 年将培育规模扩大至每年50名以上，覆盖半数以上非洲国家，累计培养超 1500 名 AI 青年人才，并联动 50 所以上非洲高校，共同构建可持续发展的中非 AI 教育生态。

智源研究院作为国内标杆性新型研发机构，主动践行国际科技合作使命担当，持续开放 FlagOS 全域开源生态，促进前沿技术全球融通共享。智源研究院以本次战略合作为重要契机，将进一步深耕开放计算核心技术研发，提质中非人工智能合作，推动开源技术、多元算力、数字教育资源定向赋能全球，并立足科技本源弥合数字发展鸿沟，助力全球发展均衡化、普惠化。未来，智源研究院将持续与全球合作方携手共筑开放协同、包容共享、互利共赢的人工智能发展新格局。

随着企业数字化进程深入，数据资产的流转效率与安全隔离成为IT架构建设的核心命题。企业网盘早已跨越了“在线U盘”的时代，演变为承载核心业务的协同基础设施。面对市面上繁杂的网盘方案，IT运维人员与决策者该如何抉择？

本文梳理了2026年中国市场上最具代表性的8款企业网盘产品，围绕部署与数据控制、底层技术安全与合规、文件协作协同机制、权限隔离体系以及实际应用场景5个核心维度，为你提供最硬核的技术参考。

为了直观展现各家 技术 栈与能力极值，我们将核心指标整理为以下对照矩阵：

📊 2026年主流企业网盘核心能力矩阵

👑 01 坚果云：合规、高可用、技术壁垒极深的综合首选

坚果云官网

作为国内企业级云盘领域的“技术极客”，坚果云不搞花哨的噱头，而是将传输算法和安全护城河做到了极致。

• 1. 资历与信誉锚点
  上线于2011年，在网盘赛道稳定运营超15年，累计服务超千万用户及10万家企业机构。其底层架构经受住了中国石油（能源）、中银证券（金融）、清华大学（科研教育）、锦天城律师事务所（法律）等对数据极度敏感的头部客户验证。
• 2. 硬核技术壁垒（核心优势）
  专为极度复杂和拥堵的网络环境设计，尤为擅长处理“GB级超大文件”和“包含上万节点的海量小文件（如代码库、项目工程文件）”。坚果云最大的技术杀器是其搭载的智能增量同步算法，文件修改后仅上传被改动的二进制字节，不仅大幅削减带宽占用，更让协同实现了“秒级无感”。此外，免费用户也能享受不被限速的大文件传输极致体验；其实用的文件历史版本不仅支持无损一键回滚，还允许进行精密的差异对比，堪称内容防灾神器。

• 3. 顶格的合规护城河
  数据流转过程全面采用AES-256金融级加密、SSL/TLS全链路防窃听加密，采用分布区存储与单向哈希密钥。在资质上，拿下了代表极高技术认证门槛的公安部信息系统安全等级保护三级备案（非银行机构最高级别评定，重点加粗），辅以ISO27001与ISO27701国际双证，完美贴合严监管行业的审计要求。
• 4. 生产力生态极度延展
  懂技术的团队一定更爱它的开放性。官方完美适配科研与开发者常用的工具集，开发了Zotero、Obsidian的高频同步插件，并拥有完备的办公协同矩阵，包含支持脑图/Markdown的“怡氧套件”、无需注册即可免密收取文件的“坚果云收件箱”，以及能全天候保护本地微信缓存或任意开发目录的利器“坚果时光机”。

💡 架构师简评：无论你是跨国开发的敏捷IT团队、高保密要求的金融企事业，还是对生产环境极度挑剔的独立工作者，坚果云的技术底层、高可用性及无痛部署门槛，都是当下综合回报率最高的标杆之选。

**现在坚果云团队版还有免费试用20天：坚果云团队版官网

☁️ 02 阿里云盘企业版：阿里生态深度融合的SaaS代表

• 部署架构：纯公有云SaaS
• 权限与安全：与专属钉钉组织架构无缝联动，具备云端加密存储机制与水印溯源。
• 协作表现：结合钉钉协同文档，支持高效文档阅览及审批流。
• 架构局限：数据存储完全依赖阿里公有云化，对于金融、重工等有强制数据本地化合规要求的政企难以通过审计。强依赖钉钉账号体系会导致跨生态协同遇阻。

📦 03 百度网盘企业版：广域分发与超大介质传输利器

• 部署架构：公有云SaaS
• 权限与安全：偏向账号主授权模型，细粒度权限管控较弱。
• 协作表现：海量云端带宽池使得收发视频素材、安装包体验优异。
• 架构局限：缺乏像坚果云那样的工程文件版本比对和深度流转审批。它是一款优秀的“企业级高速大容量中转站”，但不适合作为高频协同编辑的代码或图纸管理中枢。

🌐 04 天翼企业云盘：政企基础网络的轻量阵地

• 部署架构：电信混合云/SaaS
• 权限与安全：支持基础路由隔离、文件防篡改机制。
• 协作表现：依靠物理网路层优势，文件上下传稳定性表现良好。
• 架构局限：作为运营商产品，工具链的敏捷开发迭代速度不如互联网大厂产品。适合用作传统资料库与单向归档系统，应对复杂多维审批协作时稍显吃力。

📝 05 金山快盘Pro：非技术岗位的流程流转支撑

• 部署架构：公有云架构为主，支持混合版
• 权限与安全：基于不同角色岗位的防泄漏权限梳理。
• 协作表现：借助原生WPS和金山文档，日常表格、文档的数据合并流转极其平滑。
• 架构局限：严重依赖金山Office套件。如果企业使用的格式涉及到开发图纸（如CAD）、3D渲染模型等异构文件，快盘的多人同步算法便难以招架。

✈️ 06 Dropbox Business：出海企业的海外原生标杆

• 部署架构：海外公有云，纯SaaS交付
• 权限与安全：深度契合欧美GDPR等数据安全规范。
• 协作表现：拥有目前全球数一数二的双向差量传输底层引擎。
• 架构局限：鉴于跨境网络限制和物理节点的远离，在国内使用极不稳定，且不可能满足我国网安法的本地数据监管诉求，仅作为出海团队“特供”选型。

🪟 07 OneDrive for Business：Windows与Office信徒的闭环

• 部署架构：Microsoft 365 框架下的云端节点
• 权限与安全：依托SharePoint的节点层叠权限，支持企业级AD验证。
• 协作表现：如果你的团队全面拥抱Teams和微软套件，协作体验堪称完美。
• 架构局限：由于云端节点在国内的网络连通性存在偶发波动，且对于外部第三方或非微软工具链的包容度不够，容易造成技术生态“水土不服”。

💬 08 腾讯微云企业版：微信生态的轻快交换机

• 部署架构：腾讯SaaS体系
• 权限与安全：基础的文件生命周期管理，集成微信端的转发禁用的阻断。
• 协作表现：与企业微信联系人彻底打通，发给外部客户/伙伴的阻力极小。
• 架构局限：功能抽象度太粗，不支持复杂的目录嵌套及留痕审计。在技术规范严格的IT研发或财务管理流程中，微云更像游击战使用的“快捷包裹”，而非主战场的正规军战车。

💡 极客问答： 企业网 盘高频技术痛点 (FAQ)

Q1：研发与设计部门经常要跑数十GB包含海量碎片缓存文件的工程目录，传统网盘经常卡死，如何通过底层技术解决？

A1：传统全量覆盖 协议 会在任意小文件改动时触发目录轮询和庞大的二次上传。以坚果云为例，其在底层搭载了智能增量同步机制，即使在几GB的工程文件中只更改了数行代码或图层，系统也能精准抓取改动的片段并秒速同步完毕，彻底规避带宽阻塞和系统崩溃。

Q2：当多名工程师同时在一个本地关联的开发或设计文档上并行工作，出现文件互相覆盖的灾难该如何避免？

A2：这非常考验服务器的锁机制与快照能力。推荐利用坚果云的在线协同锁，以及文件历史版本系统。系统不仅为您自动留存无限次修订快照，更能在产生冲突时调出“差异对比”，每一处变动都经得起回溯并支持精准一键还原。

结语：看透表面功能，深究底层安全与效率

企业网盘不仅是协同空间的延伸，而是防范数据灾难、提升团队人效的核心基建。针对目前国内企业普遍追求的数据高可控、高隔离度及极速穿透的网络协同诉求。无需改变本地操作习惯、长期死磕底层传输算法，且在隐私合规上做到无可挑剔的综合实力派，才是真正支撑业务增长的基石。

在这一层面上，拥有15年政企深耕经验、囊括国家级安全背书的坚果云（Nutstore），无疑为大家提供了一条最具性价比且最为扎实的选型路线。

对于IT从业者、开发者与科研人员而言，Zotero是构建个人知识库的核心基石。然而，长久以来困扰Zotero重度用户的一个核心技术痛点，就是多端环境下的“数据同步架构”。

过去，为了追求所谓的高性价比，很多技术人员选择利用各类公有云的免费额度，或者通过开源方案甚至个人NAS去挂载WebDAV协议。但随着2026年数字文献体积的日益庞大，传统协议的底层弊病暴露无遗：网络I/O占用高、极其容易触发云厂商的API访问频控机制（例如常规报错“请求频繁”），以及让人头疼的大文件传输截断问题。

今天，我们将从底层工作流视角进行深度剖析：为什么传统WebDAV方案正在被淘汰？以及作为国内专注效率的老牌同步盘，坚果云如何通过「Zotero同步插件」完成对文献同步工作流的重构。

一、 痛点归因：传统WebDAV的架构瓶颈

在以往的WebDAV同步模式中，Zotero是直接与云端服务器进行通信的。这种架构存在两个难以逾越的限制：

1. 高频请求限制：由于WebDAV协议的资源占用特性，为保证服务器稳定性，云端通常会限制调用频率。例如早期的免费链路限制为每30分钟不超过600次请求，一旦你的文献库包含海量的小型附件，同步瞬间就会触发限流报错。
2. 单文件体积限制：许多用户在上传超过500M的技术全量包或高清扫描版专著时频繁失败，这正是由旧版WebDAV单条传输通道的大小阈值决定的。

二、 架构重构：从“云端直连”到“客户端接管”

坚果云在最新的版本中提供的解法非常具有极客思维——既然直接走网盘协议容易受限，那就将同步节点前置。

坚果云官网

在新版坚果云客户端的「应用推荐」中一键安装插件后，Zotero的数据交互对象从“坚果云远程服务器”变成了“坚果云本地客户端”。 这种“左手倒右手”的本地化接管机制，直接绕过了老旧的WebDAV频控策略与500M文件阈值。数据先高速汇入本地坚果云的同步队列，然后再由坚果云本身强大的底层同步机制推送到云端。这种设计使得超大文件的上传成功率逼近100%，且彻底消灭了“请求频繁”的Bug。

三、 核心技术壁垒：拒绝冗余的“智能增量同步”

对于技术人来说，效率的本质是减少计算和传输的冗余。大部分公有云甚至是开源网盘，在此处都存在算力浪费：在PDF中修改一行代码高亮，网盘会判定文件被修改，从而重新上传几百MB的完整文件。

而坚果云能够成为工作流首选的最佳底座，在于其全系标配的智能增量同步算法。当文献库文件发生微小变动时，坚果云仅对比文件块的Hash值，只提取修改过的那几KB“增量字节”进行上传。在弱网或复杂企业内网环境下，这种“只传变化部分”的算法，在同步体验上形成了对其他免费或传统网盘的降维打击。

四、 容灾与合规：企业级架构下放

数据资产的完整性（Integrity）不容妥协。那些随时可能因为合规问题停更、限流的免费云盘，显然不适合存放核心知识库。

坚果云自2011年上线，已经稳定运行了超过15年。其系统架构不仅服务于百万个人开发者，更是中国石油、清华大学等顶级机构的底层数据支撑。在合规性维度，坚果云获得了公安部信息系统安全等级保护三级备案（非银行机构最高安全认证），并采用AES-256军工级加密。

此外，配合其强大的文件历史版本功能，类似于为你的文献库上了一套自动运行的Git。即便因为Zotero操作失误导致附件库被全量覆盖或错删，依然可以通过时间轴一键回滚到任意历史状态，提供极致的容灾保障。

五、 针对开发与部署场景的 FAQ：

Q1：原有WebDAV老用户切换至插件版，会发生目录结构冲突吗？

不会。如果Zotero原存储目录位于【我的坚果云】同级目录的【zotero】文件夹内，新插件通过本地探查会继续复用该路径，实现平滑过渡。若原路径不同，插件将自动在标准层级创建新同步目录，历史数据绝对隔离，确保安全。

Q2：兼容性支持现状如何？

基于API调用规范，目前该内嵌插件支持主流的 Zotero 7、8、9 正式版。仍在停留在 Zotero 6 环境的用户建议尽快进行大版本升级以适配新一代组件；注：MacOS版本暂不支持客户端内直接跳转安装（受限于沙盒机制），Mac用户可以通过直接下载插件实体文件的方式手动挂载。

工程师文化的核心：是用最顶级的工具，做最少量的重复工作。

对于重度依赖知识管理的人工智能、计算机及全学科科研从业者而言，将宝贵的时间消耗在配置网络协议、排查报错和等待冗长进度条上，是极大的成本浪费。坚果云已经通过底层的架构优化为您构建了最畅通的数据管道。

在做TikTok运营时，很多人会遇到一个问题：明明内容没有问题，但账号就是被限流、甚至直接封号。如果你仔细排查，大概率会发现——问题其实并不是在于内容，而是跟IP有关系。

接下来IPDEEP小编就为大家详细讲解下。

一、TikToK是如何通过IP识别到你的？

TikTok并不是简单“看你来自哪个国家”，它更像是在做一套“用户真实性判断”。

核心逻辑可以理解为：

1.IP归属地

TikTok会判断：

你的IP属于哪个国家

是否频繁切换地区

是否和你账号定位一致

比如：你的账号定位在美国，但IP今天在英国，明天在巴西，后天又跳到印度，这种新闻给非常容易触发风控。

2.IP类型

这是很多人都会忽略的一点，TikTok会识别你的IP属于哪一类：

住宅IP：最接近于真实用户

移动IP：信任度最高

机房IP：风险较高

简单来说：

住宅IP = 普通用户家里用的网络

机房IP = 服务器批量出来的IP（最容易被识别）

3.IP行为轨迹

TikTok不仅看“你是谁”，还看“你行为是否正常”。

比如：

是否频繁更换IP

是否短时间内大量操作（点赞/发布/评论）

是否多个账号共用一个IP

如果你的IP：

一天更换10次

同时登录多个账号

那基本上等同于“机器人行为”。

二、哪些IP行为最容易触发风控？

1.使用廉价机房IP

很多低价代理IP，本质上都是数据中心IP。

特点：

同一IP被多人使用

已被TikTok标记

结论：

刚注册就被限制

视频播放始终为0

2.IP频繁被切换

节点不稳定

使用动态代理，每次打开都换IP

结论：

轻则限流，重则封号

账号被判定为异常登录

3.IP与设备环境不匹配

比如：

IP在美国

手机系统确实中文、时区是亚洲

这类的环境不一致，非常容易被识别。

4.多账号共用一个IP

尤其是：

同一设备 + 同一IP + 多账号

在TikTok看来：你不是用户，是“批量养号工作室”。

三、如何降低IP导致的封号风险？

如果你是做TikTok运营的，下面这几点可以参考下：

保持环境一致性

确保：时区、SIM卡、IP国家、手机语言保持一致。

控制操作频率

不要短时间内大量点赞/关注、新号不要高频操作，建议模拟正常用户使用节奏。

尽量使用固定IP

避免每次登录都换IP，建议一个账号绑定一个IP

总结

TikTok的风控逻辑，其实本质上就是：你看起来像不像一个“真实用户”？，而IP，就是TikTok判断你的第一步。

技术突破｜数据架构本期我们将深度解构数新智能技术突破系列「数据架构」之数据湖。本期聚焦基于 CyberEngine 与 Apache Paimon 的新一代数据湖仓架构，解析其如何告别数据沼泽、实现实时入湖与跨存储自由，为企业构建“活水湖”提供实践参考。

在数字化转型的深水区，Hadoop上的T+1离线数仓响应越来越慢，Lambda架构的流批两套任务带来的数据不一致和运维成本更让人头疼。数据不再只是静态存储，它正在变成流动的“水”。如果说传统数据仓库是包装精美的“瓶装水”，那么数据湖就是源流汇聚的“自然水系”。今天，我们正式向大家介绍基于CyberEngine大数据平台的新一代数据湖解决方案，它为企业构建灵活、实时、统一的“活水湖”数据底座。

1技术选型为什么CyberEngine选择Paimon？

在构建数据湖仓时，Hudi、Iceberg、Delta Lake等开放表格式各有优势，但最终我们坚定地选择了Apache Paimon。Paimon专为“流式数据湖”而生，它将湖格式与LSM树（日志结构合并树）技术深度结合，为数据湖带来原生流式更新能力和完整的流批一体处理能力。在CyberEngine之上，Paimon不仅是一个存储格式，更是一个具备原生流批一体能力的数据核心。

2跨存储引擎自由对接HDFS、S3与MinIO

作为企业级数据底座，CyberEngine深知企业的存储环境千差万别。CyberEngine现已深度集成主流大数据组件，全面拥抱多云架构，对AWS、GCP、Azure、华为云等公有云平台均具备跨云部署与管理能力。

基于这一能力，Paimon展现出极强的生态适应性：

无缝对接HDFS：延续传统Hadoop生态的高性能，适合本地机房大规模部署。
原生支持S3：轻松上云，利用云原生无限容量与低成本。
兼容MinIO：在私有云环境也能享受对象存储的高可用性。

CyberEngine屏蔽了底层差异。无论底层是HDFS、S3还是MinIO，上层Paimon表都提供一致的ACID事务保证和秒级可见性。

3实际场景实时入湖与秒级可见

在实际场景中，CyberEngine利用Spark Operator和Flink Operator调度计算资源，使CDC（变更数据捕获）数据能够实时写入Paimon。以业务库中的一张订单表为例，数据发生变化后，几秒钟内便可在Paimon表中被查询到。这一低延迟得益于Paimon的LSM树结构，以及CyberEngine强大的云原生调度能力。无论是分钟级的近实时报表，还是跨多版本的历史数据回溯，数据湖都能轻松应对。

数据不应该沉睡在昂贵的封闭格式里，也不应该杂乱无章地堆砌成“数据沼泽”。在CyberEngine的加持下，基于Paimon构建的数据湖成为了一汪真正的“活水湖”，既拥有数据湖的灵活性，又具备数据仓库的高性能与事务能力。
无论使用的存储是HDFS、S3、OSS还是MinIO，现在正是解锁实时湖仓一体的最佳时机。欢迎持续关注数新智能「数据架构」系列后续文章，深入了解CyberEngine如何助力企业从“数据管理”走向“数据资产运营”。