有些人刷短视频解压，有些人刷八卦上头，而有的人（懂的都懂）会定期翻 OpenJDK 的 commit log——属于那种“看别人修 bug 也能获得快乐”的硬核爱好。最近就有这么一个提交，能让人滑着滑着突然停住：一个几十行的小修，直接把 30x–400x 的性能差距抹平了。

提交信息长这样（链接转纯文本）：
https://github.com/openjdk/jdk/commit/858d2e434dd

关键点一句话：Linux 下 ThreadMXBean.getCurrentThreadUserTime() 以前走 /proc 读文件+解析，现在改成 clock_gettime() 一把梭。
听着朴实无华，但效果非常“离谱地好”。

这锅到底有多大

同门两兄弟，一个像跑车，一个像拖拉机

先认识两位主角：

• ThreadMXBean.getCurrentThreadCpuTime()：拿“当前线程总 CPU 时间”（user + system）
• ThreadMXBean.getCurrentThreadUserTime()：只拿“当前线程 user 时间”

你可能会以为：两者应该差不多吧？都是“线程 CPU 时间”嘛。
结果历史实现告诉你：想多了。

原始 bug 报告直接给出差距：
https://bugs.openjdk.org/browse/JDK-8210452

里面量化得很狠：

getCurrentThreadUserTime 比 getCurrentThreadCpuTime 慢 30x–400x

并发一上来，差距还会被放大，属于“越忙越慢，越慢越崩”。

旧实现

为了拿个 user time，JVM 竟然去读 /proc

旧版 Linux 实现藏在 os_linux.cpp 里，本质流程是：

1. 拼路径 /proc/self/task/<tid>/stat
2. open() 打开文件
3. read() 读进 buffer
4. 处理一个“恶意格式”：线程名里可能有括号，所以要找最后一个 )
5. sscanf() 抽第 13/14 个字段（user/sys tick）
6. tick 换算成纳秒

那段被删掉的代码大概长这样

static jlong user_thread_cpu_time(Thread *thread) {
  pid_t  tid = thread->osthread()->thread_id();
  char *s;
  char stat[2048];
  size_t statlen;
  char proc_name[64];
  int count;
  long sys_time, user_time;
  char cdummy;
  int idummy;
  long ldummy;
  FILE *fp;


  os::snprintf_checked(proc_name, 64, "/proc/self/task/%d/stat", tid);
  fp = os::fopen(proc_name, "r");
  if (fp == nullptr) return -1;
  statlen = fread(stat, 1, 2047, fp);
  stat[statlen] = '0';
  fclose(fp);


  // Skip pid and the command string. Note that we could be dealing with
  // weird command names, e.g. user could decide to rename java launcher
  // to "java 1.4.2 :)", then the stat file would look like
  //                1234 (java 1.4.2 :)) R ... ...
  // We don't really need to know the command string, just find the last
  // occurrence of ")" and then start parsing from there. See bug 4726580.
  s = strrchr(stat, ')');
  if (s == nullptr) return -1;


  // Skip blank chars
  do { s++; } while (s && isspace((unsigned char) *s));


  count = sscanf(s,"%c %d %d %d %d %d %lu %lu %lu %lu %lu %lu %lu",
                 &cdummy, &idummy, &idummy, &idummy, &idummy, &idummy,
                 &ldummy, &ldummy, &ldummy, &ldummy, &ldummy,
                 &user_time, &sys_time);
  if (count != 13) return -1;


  return (jlong)user_time * (1000000000 / os::Posix::clock_tics_per_second());
}

看到这里你大概已经开始皱眉：为了拿一个时间，居然要走文件系统、内核拼字符串、用户态 sscanf 解析……
这不是性能敏感路径里最忌讳的“豪华套餐”吗？

对比：CPU time 那位“亲兄弟”一直就很优雅

同样是拿时间，getCurrentThreadCpuTime() 从古至今都干净得像刚洗完的盘子：

jlong os::current_thread_cpu_time() {
  return os::Linux::thread_cpu_time(CLOCK_THREAD_CPUTIME_ID);
}


jlong os::Linux::thread_cpu_time(clockid_t clockid) {
  struct timespec tp;
  clock_gettime(clockid, &tp);
  return (jlong)(tp.tv_sec * NANOSECS_PER_SEC + tp.tv_nsec);
}

一句 clock_gettime()，没有文件 IO、没有解析、没有一堆 syscalls 组合拳。

为什么差这么多：一次 syscall vs 一串 syscall + VFS + 字符串 + 解析

旧 /proc 路径大概干了这些活：

• open() syscall
• VFS 分发 + dentry 查找
• procfs 动态生成内容
• 内核把数字格式化成字符串
• read() syscall，把内容拷回用户态
• 用户态 sscanf() 解析
• close() syscall（还可能牵扯锁、futex 等）

而 clock_gettime(CLOCK_THREAD_CPUTIME_ID) 路径基本是：

• 单次 syscall → 直接走内核里一条更短的函数链，读调度实体里的时间信息

所以差距不在“要不要进内核”（两者都要），而在进内核之后做了多少额外工作。

那问题来了：当年为啥不用 clock_gettime 拿 user time？

答案很“标准化”：POSIX 规定 CLOCK_THREAD_CPUTIME_ID 返回的是总 CPU 时间（user + system）。
“只要 user 时间”这件事，在 POSIX 意义上并没有一个通用开关。

但 Linux 有自己的“私房菜”：clockid_t 的位编码。这个编码在 Linux 内核里稳定很多年，但你在 man page 里不一定能看到它的完整说明——要想懂，得看内核源码那种“祖传注释”。

新实现

用 pthread_getcpuclockid 拿到 clockid，再把类型位翻成 VIRT（user-only）

Linux 从 2.6.12（2005 年）开始，就在 clockid_t 里编码了“时钟类型/线程或进程”等信息。pthread_getcpuclockid() 会给你一个 POSIX 合规的 clockid（通常是 SCHED：user+system）。
接着只要把低位类型从 10 翻成 01（VIRT：user-only），再交给 clock_gettime()，就能得到 user time。

新代码核心如下：

static bool get_thread_clockid(Thread* thread, clockid_t* clockid, bool total) {
  constexpr clockid_t CLOCK_TYPE_MASK = 3;
  constexpr clockid_t CPUCLOCK_VIRT = 1;


  int rc = pthread_getcpuclockid(thread->osthread()->pthread_id(), clockid);
  if (rc != 0) {
    // Thread may have terminated
    assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
    return false;
  }


  if (!total) {
    // Flip to CPUCLOCK_VIRT for user-time-only
    *clockid = (*clockid & ~CLOCK_TYPE_MASK) | CPUCLOCK_VIRT;
  }


  return true;
}

static jlong user_thread_cpu_time(Thread *thread) {
  clockid_t clockid;
  bool success = get_thread_clockid(thread, &clockid, false);
  return success ? os::Linux::thread_cpu_time(clockid) : -1;
}

对比旧实现：

• 没有 /proc
• 没有 fread buffer
• 没有 sscanf
• syscalls 数量也从“一串”变成“基本一个”

简直是“删代码删出性能”。

真实性能：从 11 微秒降到 279 纳秒，直接 40 倍起飞

为了量化差距，修复里还顺手带了 JMH benchmark（这点很加分：没有基准的优化，容易变成自我感动）。

原 benchmark 示例：

@State(Scope.Benchmark)
@Warmup(iterations = 2, time = 5)
@Measurement(iterations = 5, time = 5)
@BenchmarkMode(Mode.SampleTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Threads(16)
@Fork(value = 1)
public class ThreadMXBeanBench {
    static final ThreadMXBean mxThreadBean = ManagementFactory.getThreadMXBean();
    static long user; // To avoid dead-code elimination

    @Benchmark
    public void getCurrentThreadUserTime() throws Throwable {
        user = mxThreadBean.getCurrentThreadUserTime();
    }


    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(ThreadMXBeanBench.class.getSimpleName())
                .build();
        new Runner(opt).run();
    }
}

旧版本（/proc 路径）结果大意是：平均 ~11 微秒。
修复后结果：平均 ~0.279 微秒（也就是 279 纳秒）。
算下来差不多 40x 改善（在 30x–400x 区间内，符合历史报告范围）。

配套 profile 也很直观：旧版像“syscall 自助餐”，新版像“只吃一道菜”。

彩蛋：还能再榨出 13%？内核 fast-path：PID=0 时跳过 radix tree 查找

性能到了纳秒级还继续抠？这就很“工程师”。
在修复后的 profile 里还能看到一个小热点：内核里会做一次 radix tree lookup 去定位目标线程的 pid 结构。原因是：pthread_getcpuclockid() 返回的 clockid 编码了具体 TID，内核拿到后要去查。

但内核有个更快的分支：如果 clockid 里编码的 PID/TID 是 0，内核把它解释成“当前线程”，直接走 current task，跳过查找。

/*
 * Functions for validating access to tasks.
 */
static struct pid *pid_for_clock(const clockid_t clock, bool gettime)
{
[...]


  /*
  * If the encoded PID is 0, then the timer is targeted at current
  * or the process to which current belongs.
  */
  if (upid == 0)
      // the fast path: current task lookup, cheap
      return thread ? task_pid(current) : task_tgid(current);


  // the generalized path: radix tree lookup, more expensive
  pid = find_vpid(upid);
  [...]

于是有人提出一个“更野但更快”的想法：既然 OpenJDK 已经在改 clockid 的低位类型了，那干脆自己构造一个 PID=0 的 clockid 走 fast-path。

clockid 编码示意：

clockid (原理示意)：


// Linux Kernel internal bit encoding for dynamic CPU clocks:
// [31:3] : Bitwise NOT of the PID or TID (~0 for current thread)
// [2]    : 1 = Per-thread clock, 0 = Per-process clock
// [1:0]  : Clock type (0 = PROF, 1 = VIRT/User-only, 2 = SCHED)
static_assert(sizeof(clockid_t) == 4, "Linux clockid_t must be 32-bit");
constexpr clockid_t CLOCK_CURRENT_THREAD_USERTIME = static_cast<clockid_t>(~0u << 3 | 4 | 1);

然后把 getCurrentThreadUserTime() 直接改为用这个 CLOCK_CURRENT_THREAD_USERTIME 调 clock_gettime()。

结果呢？benchmark 从 81.7ns 降到 70.8ns，约 13% 提升。
绝对值不大，但属于“白给的快”。

当然，这也带来一个工程上的灵魂拷问：为了这点收益，值不值得在 JVM 里依赖更多 Linux 内核 ABI 细节？
这类优化就很像把车轮胎气压从 2.3 调到 2.35：能快，但你得接受“更挑环境”的风险感。

三条硬核经验：写性能代码时，别只信标准，别只信直觉

这次修复能这么漂亮，背后有三条特别“值钱”的经验：

1）别只读 POSIX，要敢读内核源码
标准告诉你“可移植的下限”，内核源码告诉你“可用的上限”。两者之间有时差着 400 倍。

2）别迷信老实现里的假设
当年的 /proc 解析可能是合理折中，但假设会“固化”成代码，一固化就是十几年。隔段时间回头看，往往能捡到大便宜。

3）优化要带基准，要留证据
这次提交很关键的一点：带了 JMH benchmark。否则这种改动很容易被质疑为“玄学改法”。

结尾：JDK 26 可能给你“免费加速包”

这个改动在 2025-12-03 落地，距离 JDK 26 冻结只差一天。文章里也给了时间点：JDK 26 预计 2026 年 3 月发布。
如果你的系统里确实用到了 ThreadMXBean.getCurrentThreadUserTime()（比如 profiling、监控、诊断工具链），那这波升级基本等于：白捡一个数量级的延迟下降。

喜欢就奖励一个“👍”和“在看”呗~

开发者朋友们大家好：

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术

1、谷歌发布 Gemini 3 Deep Think，编程水平排名世界第八

今天凌晨，谷歌发布了 Gemini 3 Deep Think 的重大升级。作为专用于复杂任务的推理模式，该版本试图解决科学与工程领域的诸多挑战。据悉，去年 9 月加入 Google DeepMind 的清华物理系校友姚顺宇也参与了此次研发。

在编程领域，Gemini 3 Deep Think 在 Codeforces 平台上取得了 3455 的 Elo 分数，位列世界第八。这意味着全球仅有 7 名人类选手能在此类比赛中击败它，而此前最佳模型 OpenAI o3（约一年前数据）的排名仅为第 175 位。

该模型在多项学术基准测试中刷新了纪录：

• 通用与抽象推理：在「人类的最后考试」基准测试中，不使用工具取得了 48.4% 的 SOTA 成绩；在 ARC-AGI-2 中达到 84.6%。值得注意的是，其在 ARC-AGI-1 上的每任务成本仅为 7.17 美元，相比 OpenAI o3-preview 「高计算」版本降低了数百倍。
• 科学竞赛：在 2025 年国际数学、物理和化学奥林匹克竞赛笔试中均获金牌水平，并在高等理论物理 CMT-Benchmark 测试中得分 50.5%。

谷歌同时展示了 Deep Think 在科研中的实际应用。罗格斯大学数学家 Lisa Carbone 利用其识别出一篇专业论文中人工评审未发现的逻辑缺陷；杜克大学 Haozhe Wang 的实验室则利用其优化半导体工艺，实现了厚度大于 100 微米薄膜的精确生长目标。此外，该模型还能将草图转化为可 3D 打印的实体模型。

目前，全新 Deep Think 已面向 Google AI Ultra 订阅用户及部分 API 合作伙伴开放。

（@机器之心）

2、小红书开源工业级语音系统 FireRedASR2S：集成四大核心组件

2026 年 2 月 12 日，小红书正式发布并开源了工业级一体化语音识别系统 FireRedASR2S。该项目基于 Apache-2.0 许可协议，相关的模型权重与推理代码目前已在 Hugging Face 和 ModelScope 等平台开放下载。

FireRedASR2S 将单点语音能力扩展为了完整的处理生态，系统内部集成了ASR（自动语音识别）、VAD（语音活动检测）、LID（语种识别）和 Punc（标点预测）四个核心组件。这些模块在架构设计上保持自包含与独立性，开发者既可以将其整合为端到端的工作流，也能脱离主系统单独调用任意单个模块。

根据官方公布的基准测试数据，各核心组件的具体能力表现如下：

• FireRedASR2：支持普通话、20 多种方言与口音、中英文语码转换以及歌词识别。该模块提供 LLM（结合大语言模型以优化无缝交互）与 AED（平衡性能与效率，支持词级时间戳）两个版本。评测显示，其普通话平均字符错误率（CER）低至 2.89%，方言平均 CER 为 11.55%，整体表现优于 Doubao-ASR、Qwen3-ASR-1.7B 与 Fun-ASR 等竞品。
• FireRedVAD：支持超百种语言的非流式与流式语音活动检测，涵盖语音、歌声及音乐，并具备音频事件检测能力。其 F1 分数高达 97.57%，领先其他开源基准。
• FireRedLID：覆盖 100 多种语言及 20 多种中文方言，语种检测准确率达到 97.18%，客观数据超越了 Whisper 与 SpeechBrain-LID。
• FireRedPunc：提供多领域的中英文标点预测服务，平均 F1 分数达到 78.90%，显著优于 FunASR-Punc。

在实际应用与部署环节，系统要求输入 16kHz 16 位单声道 PCM 格式音频。对于输入长度，AED 版本最高支持 60 秒的音频，而 LLM 版本目前支持最长 30 秒的输入。后续，开发团队还将陆续公开技术报告与微调代码。

GitHub:
https://github.com/FireRedTeam/FireRedASR2S

HuggingFace:
https://huggingface.co/FireRedTeam/FireRedASR2-AED

( @GitHub)

3、涉嫌侵犯开源项目 FFmpeg 的版权，瑞芯微被 GitHub 冻结代码库

2026 年 2 月，国内芯片设计企业瑞芯微（Rockchip）因涉嫌侵犯开源项目 FFmpeg 的版权，其相关代码库被 GitHub 平台冻结。这一事件再次引发行业对开源软件合规使用的关注。

经查，瑞芯微在产品开发过程中使用了 FFmpeg 的核心组件 libavcodec 代码，但在使用过程中存在多项违规操作：

• 删除版权信息：删除了代码原作者信息及版权声明；
• 篡改许可证：擅自将原代码的 LGPL 许可证更改为 Apache 协议。

尽管 LGPL 协议允许商业场景使用，但明确要求使用者必须保留原始版权声明、按需提供源代码，并保持许可证的一致性。瑞芯微的操作直接违反了这些条款。事实上，该违规行为早在 2024 年初就已被发现。当时，瑞芯微工程师 HermanChen 曾公开道歉，称对许可证冲突缺乏了解，并承诺整改。然而，在随后的近两年时间里，瑞芯微并未采取实质性整改措施。最终，FFmpeg 项目方依据《数字千年版权法案》（DMCA）向 GitHub 发起正式投诉，导致瑞芯微相关项目库被冻结。

数据显示，目前 97% 的代码库包含开源组件，其中 63% 存在许可证冲突。业内专家指出，许多企业开发者对 GPL、MIT、Apache、LGPL 等主流许可证的区别认知不足，错误地认为开源代码可随意修改分发，从而埋下法律风险。

不同许可证规则差异显著。以此次涉事的 LGPL 为例，它允许闭源软件动态链接使用，仅要求修改库本身代码时开源修改部分；而 Apache 协议虽支持商业闭源，但更侧重专利保护，且与 GPL 系列协议存在兼容性冲突，二者不可随意替换。此次事件表明，开源合规管理已成为企业发展的必修课，企业需建立完善的审查机制，明确协议边界，规避版权风险。

（@人人极客社区）

4、蚂蚁百灵开源发布万亿参数思考模型 Ring-2.5-1T ，主打深度思考与长程智能体执行

今天中午，蚂蚁百灵正式发布并开源了首个混合线性架构的万亿参数思考模型 Ring-2.5-1T。作为迈向通用智能体时代的关键一步，该模型在预训练和强化学习层面均进行了大规模扩展。

相比前代产品 Ring-1T，Ring-2.5-1T 在三个核心维度实现了大幅提升：

• 高效生成：基于高效的 1:7 MLA + Lightning Linear Attention 架构，在超过 32K 的生成长度下，访存规模降低 10 倍以上，生成吞吐提升 3 倍以上。
• 深度思考：在 RLVR 基础上引入 dense reward 反馈机制。自测结果显示，其在 IMO 2025（获 35 分）和 CMO 2025（获 105 分）中均达到金牌水平。
• 长程执行：通过大规模全异步智能体强化学习（fully-async agentic RL）训练，显著增强了复杂任务的长程自主执行能力，可适配 Claude Code 及 OpenClaw 等框架。

在架构层面，Ling 2.5 采用增量训练方式，将 Ling 2.0 的 GQA 升级为混合线性注意力结构。改造后，尽管激活参数量从 51B 增至 63B，但推理效率仍大幅提升。测试显示，无论在单机 8 卡 H20-3e 还是 H200 环境下，其长程推理的吞吐优势均十分显著。

为验证其长程执行能力，开发团队将 Ring-2.5-1T 接入 Claude Code，仅用两小时便自动完成了一个微型版操作系统（TinyOS）的开发，并能进一步实现 bash 功能。此外，该模型在数学、代码、逻辑等高难推理任务以及智能体搜索（如 GAIA2-search）等长程任务执行上，均达到了开源领域的领先水平。

目前，Ring-2.5-1T 仍存在 token efficiency 和指令遵循方面的局限性。其模型权重已在 Hugging Face 和 ModelScope 开源，相关体验页及 API 服务也将在 Ling Studio 与 ZenMux 陆续上线。

HuggingFace:

https://huggingface.co/inclusionAI/Ring-2.5-1T

（@百灵大模型）

02 有亮点的产品

1、自然语言几分钟构建 AI 智能体：VM0 正式开启公开测试

2026 年 2 月 6 日，VM0 宣布正式开启公开测试。在经历了约两个月的内部构建与私密测试后，该平台现已向更多开发者开放。

VM0 是一款基于自然语言构建 AI 智能体的工具，并配备了支持智能体全天候（24/7）运行的沙盒环境。 用户只需用自然语言描述具体需求，VM0 便会自动处理运行时、执行操作及环境配置。即使用户关闭了电脑，其部署的智能体应用也会保持持续运行状态。

在构建体验上，该平台试图同时满足不同类型用户的需求：

• 面向 Vibe Coder 和快速实验：对于刚接触 AI 智能体或希望快速测试想法的用户，平台提供了几分钟即可上手的体验。无需繁重的环境设置或提前阅读长篇文档，仅需执行一条简单的初始命令（npm install -g @vm0/cli && vm0 onboard），即可运行首个智能体。
• 面向专业开发者：如果需要获取更多控制权，VM0 提供了一套完整的开发工具包。开发者可以将 VM0 接入现有的基础设施中，并在实际需要时进行规模化扩展。

由于目前产品仍处于测试阶段，官方正积极向早期用户征集错误报告、细节打磨建议以及功能反馈，这些反馈将直接塑造产品的下一步走向。此外，VM0 正在建设一个由社区驱动的 Cookbook，鼓励开发者分享其实际构建的案例，例如客户支持智能体、数据分析工作流或内部工具等。

根据公布的路线图，VM0 下一步的发展计划包括：推出自托管运行程序、简化的智能体分享功能、支持更多模型提供商、VM0 平台智能体构建器、VM0 Slack 集成以及 VM0 连接器。

相关链接：
https://docs.vm0.ai/docs

( @VM0 Blog)

2、AI 数字孪生初创公司 Simile 获 1 亿美元融资，用 AI 模拟真实用户反馈

AI 数字孪生初创公司 Simile 宣布完成 1 亿美元融资。本轮融资由 Index Ventures 领投，Bain Capital Ventures 等机构投资者跟投，AI 先驱李飞飞与 OpenAI 联合创始人 Andrej Karpathy 也参与了投资。

企业在推出新产品前，通常需要收集潜在客户的反馈，但这类调研往往耗时费力，且难以触及特定目标受众（如世界 500 强高管）。为此，Simile 构建了一个 AI 模型，利用个人数据来模拟人们对新产品、功能变更等商业动态的反应。目前，其首批客户包括 CVS Health Corp。 和澳大利亚最大的移动互联网提供商 Telstra Group。

该 AI 模型主要帮助企业简化以下测试流程：

• 用户界面更新评估：开发者可在向真实客户全面推出更新前，观察模拟用户对界面变更的反应。
• 财报电话会议准备：据首席执行官 Joon Sung Park 透露，在一次模拟电话会议中，该模型准确预测了分析师 10 个问题中的 8 个，能够帮助上市公司高管提前做好准备。

Simile 由 Joon Sung Park、Michael Bernstein 和 Percy Liang 共同创立。这三位计算机科学家此前曾开发过模拟环境 Smallville，证明了 AI 智能体不仅能模拟个体行为，还能模拟群体行为。据报道，Simile 耗时七个月开发该模型，其训练数据来源于对数百人的采访记录、交易日志以及科学期刊文本。

Index Ventures 合伙人 Shardul Shah 表示，Simile 建立了高保真模型来解答真实人类会做什么以及为什么这样做，这在各类组织中有着广泛的应用需求。除了模拟买家行为，AI 生成模拟正被广泛应用于更多领域，例如 Simile 的投资人李飞飞曾于 2024 年创办 World Labs，用于生成三维虚拟环境以训练工业机器人。

( @SiliconAngle)

03 有态度的观点

1、DeepMind CEO：AI 在未来十五年会解决人类棘手难题

近日，Google DeepMind CEO 德米斯 · 哈萨比斯接受《财富》杂志的采访时，其提到：人类正站在「科学发现新黄金时代」的边缘，尽管未来 10 到 15 年将经历剧烈的行业洗牌与阵痛，但最终将迎来一场足以媲美「文艺复兴」的技术变革。

哈萨比斯在访谈中提出了「激进富足」的概念。他预言 AI 将通过对科学方法的深度内化，解决人类最棘手的难题：

• 医疗革命： 未来 15 年内，AI 将使个性化医疗成为常态，攻克重大疾病。
• 能源突破： AI 将加速核聚变与太阳能新材料的研发，彻底解决能源危机。
• 宇宙探索： 算力的突破将最终支持人类「在星际间穿梭，探索银河系」。

采访中，哈萨比斯也提到了 Google 在当今 AI 圈的一些风险以及挑战。

面对 OpenAI 等竞争对手的崛起，哈萨比斯坦言谷歌必须面临「创新者困境」。他强调：「如果我们不进行自我颠覆，别人就会动手。你最好按自己的节奏来。」

据悉，随着 Gemini 系列模型及 Nano Banana 图像生成模型的发布，Alphabet（Google 母公司）股价在去年飙升约 65%，哈萨比斯认为公司已跨越了 AI 助手辅助高阶研究的「分水岭」。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考

“Fatal error: require(): Failed opening required...” 以及如何彻底避免它再次出现

凌晨两点，值班告警响了。生产环境 API 开始报 500，而且只出现在新扩容的节点上。你打开日志，熟悉又刺眼的报错跳了出来：

本地一切正常，测试环境也没问题。但在云原生部署这种“环境随时变化”的现实里，一个看起来不起眼的路径差异，就足以把服务直接打趴。

这并不是什么“新手失误”，而是很多人对 PHP 最基础能力——文件加载机制——理解不够深入导致的系统性问题。

早期 PHP 时代，我们把 include 和 require 当积木用来拼页面。到了 PHP 8.2+、Composer、容器化微服务的今天，这组函数仍然在引擎核心位置。但现实中，很多开发者依旧把它们当成“设完就不用管”的工具。

如果你想从“写脚本”走向“做稳定系统”，就必须搞清楚：当一个文件被加载进另一个文件时，底层到底发生了什么。

这篇文章会从运行机制、线上常见坑和工程实践三层，讲清楚怎样把 PHP 文件加载写到足够稳。

底层到底在发生什么？

当你执行 include 'file.php'，并不是“复制粘贴代码”这么简单。PHP 实际上会让当前执行流程暂停，切换到目标文件，把它编译为操作码，再在当前作用域里执行。

文件加载的四种形式

PHP 有四种主加载方式，它们不是语法糖，而是行为差异：

• include：温和模式。文件不存在时抛 Warning，脚本继续执行。
• require：强制模式。文件不存在时直接致命错误并中断执行。
• include_once / require_once：在前两者基础上增加“是否已加载”检查，避免重复声明。

理解这个差异非常关键：在现代业务系统里，很多核心依赖一旦缺失，不应该“带伤继续跑”。

一个更实用的心智模型：作用域注入器

可以把文件加载理解成“作用域注入器”：

• 在函数内部 include，被加载文件里定义的变量只在该函数作用域可见。
• 在脚本顶层 include，变量会进入全局作用域。

另外，很多人误判性能瓶颈。真正重的通常不是代码执行本身，而是文件状态检查（stat 调用）：

每次 include，PHP 都要向操作系统确认：文件是否存在、权限是否可读、最后修改时间等。在高并发 API 中，这个动作每秒成千上万次时，开销会非常明显。

PHP 是如何解析路径的

当你写 include 'utils.php'; 这种相对路径时，PHP 会依次尝试：

• 当前脚本目录
• php.ini 中 include_path 指定的目录
• 当前工作目录（cwd）

问题就出在这里：它有环境依赖。

比如你的命令行任务进程工作目录是 /var/www/，而 Web 进程工作目录是 /var/www/public/，同一行相对路径代码可能一个能跑、一个直接崩。

最容易把线上搞崩的 5 类错误

这些是我在遗留项目重构里反复见到的高频问题。

相对路径陷阱

错误写法：include 'includes/header.php';

为什么会发生：本地启动目录刚好是项目根目录，所以一直“看起来正常”。

线上后果：一旦被子目录调用、被定时任务调用，或者入口目录变了，路径上下文就变了。这是“我本地没问题”类事故的头号来源。

_once 的性能税

错误写法：在高频循环里大量使用 require_once。

为什么会发生：担心 Cannot redeclare class 之类的重复声明。

线上后果：每次 _once 都会触发已加载表检查。PHP 8 虽然优化了很多，但它依然比直 require 慢。依赖关系清晰的模块化系统，不该长期依赖引擎“二次确认”。

用 @ 把报错静音

错误写法：@include 'optional_config.php';

为什么会发生：想省掉 if (file_exists(...)) 的显式判断。

线上后果：你把真正问题藏起来了。文件读取失败可能不是“文件不存在”，而是权限不对（如 chmod）。报错被吃掉后，排障时间会从 5 分钟拉到几小时。

动态 include 引发路径穿越

错误写法：include $_GET['page'] . '.php';

为什么会发生：图省事做“动态路由”。

线上后果：严重安全风险。攻击者可构造 ../../../../etc/passwd，或利用 php://filter/... 读取敏感配置。即使关闭远程 URL 加载，本地文件同样会被攻击。

加载带副作用的文件

错误写法：一个文件既定义类，又直接执行逻辑（输出 HTML、连数据库等）。

为什么会发生：历史代码里职责边界没分清。

线上后果：测试几乎没法写。你只是想测试类定义，却被迫触发数据库连接和页面输出。

正确做法（PHP 8+）

在现代项目里，类加载通常由 Composer + PSR-4 自动加载处理，include/require 更多用于配置、模板和少量模块逻辑。

但即便如此，也建议守住下面三条。

始终使用绝对锚点路径

把路径固定在已知根上。__DIR__ 永远指向“当前文件所在目录”，不会随工作目录变化。

错误示例（脆弱）

<?php
// 如果从 public/ 目录启动，这里可能失败
require 'config/settings.php';

正确示例（稳定）

<?php
// 无论从哪里调用，都能稳定解析
require __DIR__ . '/config/settings.php';

善用加载返回值

这是 PHP 里经常被忽略但非常实用的能力：被加载文件可以 return 值。

config.php

<?php
return [
    'db' => [
        'host' => '127.0.0.1',
        'pass' => $_ENV['DB_PASS'] ?? 'root',
    ],
    'debug' => false,
];

app.php

<?php
$config = require __DIR__ . '/config.php';
// $config 是局部变量，不污染全局

关键组件要做防御式加载

对于必须存在的文件，不要依赖默认报错，自己把预期写清楚。

<?php
$templatePath = __DIR__ . '/views/header.php';
if (!file_exists($templatePath)) {
    throw new \RuntimeException("关键视图组件缺失: {$templatePath}");
}
require $templatePath;

生产环境注意点：扩缩容与安全

当系统从单机走到容器集群或函数计算，文件加载不再只是代码细节，而是基础设施问题。

安全：路径穿越防护

很多“PHP 不安全”的印象，本质是加载策略不安全。

• 白名单（Allow-list）：绝不直接信任用户输入拼路径。
• basename()：确实需要用输入值时，先做路径片段清洗，拦截 ../ 穿越。
• open_basedir：在 php.ini 限制 PHP 可访问路径范围，防止越界读取。

性能：OPcache 是基础设施而不是可选项

生产环境应开启 OPcache。它会把预编译后的字节码放内存，避免每次请求重复解析文件。

部署提示：在高并发集群中可以考虑 opcache.validate_timestamps=0，换取更快加载速度；但这意味着每次发布都必须做平滑重载，否则代码更新不会生效。

可观测性：失败必须可追踪

文件加载失败不应只留下一个“白屏”或 500。

• 可追踪信息：日志至少要包含 include_path 与 cwd。
• 监控策略：对 E_COMPILE_ERROR 做专门告警，这类问题通常与发布或环境差异有关，需优先回滚。

部署形态差异（容器 vs 函数计算）

容器镜像里文件路径通常固定可预测；函数计算环境常见只读文件系统、目录映射变化。统一使用 __DIR__ 能显著降低环境差异带来的路径问题。

真实事故："空配置"幽灵

我曾参与排查过一个支付业务事故：后台任务随机失败。问题根因是他们用 include 加载环境配置。

某次发布脚本漏拷了生产配置文件。因为是 include，进程没有崩，业务继续跑，只是拿到一个空的 $config。

结果是任务带着空 API 密钥连续运行了 6 小时，造成大量交易失败。

如果当时使用的是 require，任务会第一时间中断并触发告警，损失会小得多。

一句话：没有它系统就不能活，那就必须 require。

排障清单（看到 Failed opening required 时直接照做）

1. 打印绝对路径：
   var_dump(realpath(__DIR__ . '/your-file.php'));
   若返回 false，说明文件根本不在你以为的位置。
2. 确认运行身份：
   echo exec('whoami');
   看当前系统用户是否有读权限。
3. 排查隐藏语法错误：
   某些文件不是“不存在”，而是语法错误导致加载失败。
   用命令行执行：php -l filename.php。
4. 检查 PHP 开始标签：
   文件应以 <?php 开头。若短标签关闭而你写了 <?，后续可能出现各种诡异问题（如 header 已发送）。

更专业的加载封装示例

不要长期依赖裸 var_dump。建议用结构化日志和统一包装。

<?php
/**
 * 带可观测性的文件加载器
 * 开发环境要“响亮失败”，生产环境可控降级。
 */
function load_component(string $filePath, array $context = []): mixed
{
    $absolutePath = realpath($filePath);
    if (!$absolutePath || !file_exists($absolutePath)) {
        error_log(sprintf(
            "[FileLoader] Failure: %s | CWD: %s | User: %s",
            $filePath,
            getcwd(),
            get_current_user()
        ));

        if (getenv('APP_DEBUG') === 'true') {
            throw new \Exception("组件不存在: {$filePath}");
        }

        return null; // 生产环境按约定降级
    }

    extract($context);
    return require $absolutePath;
}

常见问题

Q：require_once 一定比 require 更好吗？

不一定。require_once 更像是组织不清晰时的安全网。依赖关系明确、自动加载健全时，require 更直接、性能更好。

Q：可以根据数据库值动态 include 文件吗？

可以，但必须非常谨慎。推荐白名单映射：数据库只存 ID，代码里把 ID 映射到固定路径，不要把路径原文存进数据库后直接加载。

Q：加载大文件会拖慢应用吗？

开启 OPcache 后，首次之后基本没有“解析”成本；但文件中的业务逻辑仍要执行，依旧消耗 CPU 和内存。文件内容要聚焦，避免把大量无关逻辑塞在一起。

Q：模板文件适合用 include 吗？

小项目可以。中大型系统建议使用成熟模板方案，能在安全性和复用性上更稳。

结语

把 include 和 require 用好，不只是语法问题，而是工程能力问题。

你的代码运行在操作系统、权限模型、缓存机制和部署流水线共同构成的环境里。只理解“本地能跑”，远远不够。

最佳实践小结

• 快速失败：关键依赖统一使用 require。
• 路径绝对化：避免相对路径，优先 __DIR__。
• 作用域收敛：用 return 返回配置，避免全局变量污染。
• 失败可观测：把加载失败当成一类关键系统事件处理。

你的下一步

现在就打开项目，全局搜索 include / require：

凡是不以 __DIR__ 或统一根路径常量开头的，今天就改。

这一步做完，你的生产环境就会少一类高概率事故。
Fatal error: require(): Failed opening required...”—以及如何彻底避免它再次出现

要将文件复制到 Linux 中的多个目录，可以使用 cp 和 xargs 命令。所有目标目录都将作为标准输入管道连接到 xargs 命令，示例如下：

echo dir1 dir2 dir3 | xargs -n 1 cp -v file.txt

这将复制文件 file.txt 到 dir1，dir2 和 dir3 目录。

或者，使用 for 循环将文件复制到多个目录，示例如下：

for dir in dir1 dir2 dir3; do
    cp file.txt $dir
done

也可以使用 find 命令将文件复制到多个目录，示例如下：

find dir1 dir2 dir3 -type d -exec cp file.txt {} \;

注意： 确保您具有将文件复制到目标目录的必要权限。

我的开源项目

• course-tencent-cloud（酷瓜云课堂 - gitee仓库）
• course-tencent-cloud（酷瓜云课堂 - github仓库）