Oracle笔试面试题深度拆解:从SQL底层机制到实战能力迁移
1. 为什么Oracle的笔试题总让人“一看就会一做就废”聊Oracle笔试面试题之前先得把一件事说透Oracle的题目设计思路和很多互联网大厂完全不是一个路子。互联网公司偏爱算法题考的是你临场推导的能力而Oracle这类企业级数据库厂商的笔试考的是你对数据库底层机制的理解深度和SQL实战的肌肉记忆。我带过几个准备Oracle面试的朋友他们最大的感受就是——题目单看每个字都认识但组合起来就不知道从哪下手。这个项目标题“Oracle 笔试面试题详解”看起来像是一份题库整理但真正有价值的部分不是题目本身而是题目背后暴露出来的知识盲区。你做完一套题错的那些地方恰恰就是你平时写SQL时靠“试出来”而不是“想明白”的地方。所以这篇内容我打算换个角度来写不按题型分类而是按知识模块来拆把每道典型题当成一个入口往深了挖它考的是什么、为什么这么考、实际工作中怎么用。适合谁来读如果你是刚毕业准备数据库方向岗位的这篇能帮你建立一套完整的知识框架如果你已经工作两三年想跳槽到更偏数据库内核或DBA方向的岗位这篇能帮你把零散的经验串成体系。我不会只给你答案我会告诉你出题人到底想筛掉什么样的人。2. 笔试题目背后的知识模块拆解2.1 SQL基础题为什么总能埋坑先看一道很典型的题SELECT * FROM employees WHERE salary (SELECT AVG(salary) FROM employees);这题看起来简单到不行但面试官真正想考的是子查询的执行方式。很多人张口就说“先算平均工资再逐行比较”这个回答在逻辑上没错但在执行层面太粗糙了。Oracle的优化器可能会把这种非相关子查询转换成一次性的标量计算也可能在某些版本和统计信息下走FILTER操作。你要能说出“这个子查询不依赖外层行所以理论上只需要执行一次”这才算摸到了门槛。再比如这道SELECT department_id, COUNT(*) FROM employees GROUP BY department_id HAVING COUNT(*) 5;考的是WHERE和HAVING的区别但真正的坑在于如果我把条件改成WHERE department_id 10放在GROUP BY之前和之后结果一样吗很多人会愣一下。答案是逻辑上一样但执行计划不同——放在WHERE里会先过滤再分组放在HAVING里会先分组再过滤。数据量大的时候这个差异就是几秒和几分钟的区别。注意笔试里凡是出现GROUP BY的题先看过滤条件能不能下推到WHERE这是最基本的优化意识。2.2 多表连接题的隐藏考点连接查询是Oracle笔试的重灾区。我统计过自己见过的题目大概有三分之一都涉及多表连接。但出题人不会直接问你“写一个左连接”而是会这样问“查询每个部门的名称和该部门员工的最低工资包括没有员工的部门。”这道题的关键词是“包括没有员工的部门”这就是在考外连接。但更深一层它在考你连接条件的放置位置。如果你写成SELECT d.department_name, MIN(e.salary) FROM departments d, employees e WHERE d.department_id e.department_id() GROUP BY d.department_name;这是Oracle传统的外连接语法加号放在哪一边是有讲究的。加号在e那边表示e是可选表d是主表。如果你把加号放反了结果就完全不对。现在更推荐用ANSI标准的LEFT JOIN写法但很多老系统里还是这种老语法笔试也爱考。还有一个更隐蔽的坑连接和过滤的顺序。看这道题SELECT d.department_name, e.last_name FROM departments d LEFT JOIN employees e ON d.department_id e.department_id WHERE e.salary 5000;问这个查询会返回没有员工的部门吗答案是不会。因为WHERE条件在连接之后执行e.salary为NULL的行会被过滤掉。如果你想让没有员工的部门也显示出来必须把条件放到ON子句里SELECT d.department_name, e.last_name FROM departments d LEFT JOIN employees e ON d.department_id e.department_id AND e.salary 5000;这个区别在实际工作中极其重要我见过不止一个工作了三四年的人在这里翻车。2.3 事务与锁的题目怎么答到点子上事务相关的笔试题通常以选择题或简答题出现比如“以下关于事务隔离级别的描述哪个是正确的”这种题如果你只背了四种隔离级别的名字大概率会选错。因为Oracle的默认隔离级别是READ COMMITTED但它实现的机制和标准SQL定义的READ COMMITTED有细微差别——Oracle用的是多版本一致性读读操作不会阻塞写操作写操作也不会阻塞读操作。这个特性在笔试里经常被拿来和别的数据库做对比。再比如这道经典题“一个会话执行了UPDATE但未提交另一个会话查询同一行数据会看到什么”答案是看不到未提交的修改因为Oracle的一致性读会从UNDO表空间里 reconstruct 出修改前的数据。但如果你追问“那第二个会话能更新这一行吗”答案就变成了会被阻塞直到第一个会话提交或回滚。这就是读不阻塞写、写阻塞写的典型场景。实操心得回答事务题的时候一定要把“读”和“写”分开说不要笼统地说“会锁”或“不会锁”。Oracle的锁机制是行级锁而且没有读锁这一点和很多人的直觉相反。2.4 索引与执行计划的送分题与送命题索引相关的题目简单的很简单难的能难倒一片。简单题比如“什么情况下索引会失效”标准答案能列一堆在索引列上使用函数、隐式类型转换、使用NOT、使用IS NULL、前导通配符的LIKE等等。但面试官真正想听的是为什么。比如为什么在索引列上用函数会导致失效因为B树索引存的是列的原值你套个UPPER函数索引里没有UPPER后的值自然用不上。除非你建的是函数索引。难题比如“一个表有100万行索引列有大量重复值查询返回20%的数据走索引还是全表扫描”这题考的是选择率的概念。当返回数据量占比很高时走索引反而更慢因为要回表。Oracle的优化器会根据统计信息计算成本但统计信息可能过时所以有时候需要手动干预。笔试里如果问到“为什么执行计划突然变了”八成是在考统计信息收集的问题。-- 查看执行计划的常用命令 EXPLAIN PLAN FOR SELECT * FROM employees WHERE department_id 50; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);注意笔试里如果让你写执行计划分析不要只写“走索引”或“全表扫描”要写出访问路径和连接方式比如“INDEX RANGE SCAN”和“NESTED LOOPS”。3. 从题目到实战的完整推演过程3.1 一道综合题的完整拆解来看这道题我把它称为“笔试里的终极缝合怪”“查询每个部门中工资最高的员工信息如果最高工资有多个员工全部列出。同时显示该部门的平均工资和员工人数。”这道题考了至少五个知识点分组聚合、子查询、连接、排名函数、空值处理。我一步步拆给你看。第一步先找每个部门的最高工资SELECT department_id, MAX(salary) AS max_sal FROM employees GROUP BY department_id;第二步把这张结果表和原表连接找出工资等于最高工资的员工SELECT e.*, d.max_sal, d.avg_sal, d.cnt FROM employees e JOIN ( SELECT department_id, MAX(salary) AS max_sal, AVG(salary) AS avg_sal, COUNT(*) AS cnt FROM employees GROUP BY department_id ) d ON e.department_id d.department_id AND e.salary d.max_sal;但这里有个坑如果某个部门有两个人工资都是最高这个写法会把两个人都查出来没问题。但如果某个部门的最高工资是NULL呢MAX会忽略NULL但连接条件e.salary d.max_sal在NULL的情况下不会匹配。所以更稳妥的写法是用排名函数SELECT * FROM ( SELECT e.*, AVG(salary) OVER (PARTITION BY department_id) AS avg_sal, COUNT(*) OVER (PARTITION BY department_id) AS cnt, RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rk FROM employees e ) WHERE rk 1;这个写法更优雅而且能处理NULL的情况NULL在ORDER BY DESC里默认排最后。但笔试的时候面试官可能故意不让你用窗口函数就是想看你会不会用基础语法实现同样的逻辑。实操心得窗口函数是Oracle笔试的加分项但不要一上来就用。先写基础解法再补一句“如果允许用窗口函数可以这样优化”这样既展示了基本功又体现了进阶能力。3.2 参数计算与选择率的实际推演笔试里经常出现“该走索引还是全表扫描”的判断很多人凭感觉答其实是可以算的。我教你一个简化版的估算方法。假设一个表有10000行每行200字节块大小8KB。全表扫描需要读的块数大约是10000 * 200 / 8192 ≈ 244 块如果索引列的选择率是1%也就是返回100行。走索引需要读索引块假设索引高度为2需要读3个索引块加上回表读100个数据块总共约103个块。这时候走索引更快。但如果选择率是20%返回2000行回表就要读2000个块假设每行在不同块里加上索引块总共超过2000块远大于全表扫描的244块。这时候全表扫描更快。Oracle的优化器就是基于类似的成本计算来选择执行计划的。笔试里如果给你具体数字你可以用这个思路去估算。如果没给数字你就说“取决于选择率和聚类因子”聚类因子越接近块数索引回表的成本越低。选择率返回行数索引成本估算全表扫描成本建议1%100约103块244块走索引5%500约503块244块看聚类因子20%2000约2003块244块全表扫描3.3 笔试现场的时间分配策略Oracle笔试通常题量不小我见过一套题有50道选择加5道SQL手写。时间分配很关键。我的建议是选择题平均每题不超过1分钟。遇到不确定的先标记不要死磕。很多选择题考的是细节记忆想太久反而容易选错。SQL手写题每题留8-10分钟。先写框架再补细节。如果卡住了先把能写的部分写上比如FROM和WHERE再慢慢补SELECT和GROUP BY。简答题每题5分钟。分点作答不要写大段文字。面试官看的是关键词不是你的文笔。注意如果笔试是在线平台注意保存。我见过有人写了半小时的SQL因为页面刷新全没了。每写几行就CtrlS或者先在本地编辑器写好再粘贴。4. 常见问题与排查技巧实录4.1 笔试中容易混淆的概念速查表下面这张表是我自己整理的高频混淆点笔试前过一遍能救回不少分。混淆点正确理解常见错误WHERE vs HAVINGWHERE在分组前过滤行HAVING在分组后过滤组在WHERE里用聚合函数UNION vs UNION ALLUNION去重并排序UNION ALL不去重不排序以为UNION ALL更快所以总是用它TRUNCATE vs DELETETRUNCATE是DDL不可回滚重置高水位DELETE是DML可回滚以为TRUNCATE可以带WHERERANK vs DENSE_RANKRANK跳号1,2,2,4DENSE_RANK不跳号1,2,2,3在需要连续排名时用错隐式转换字符串和数字比较时Oracle把字符串转成数字以为索引还能用NULL比较NULL不能用比较要用IS NULL写WHERE col NULL外连接加号()放在可选表一侧放反了导致结果集错误序列.nextval每次调用都递增回滚不恢复以为事务回滚会重置序列4.2 手写SQL时的排查思路笔试手写SQL最怕的是写完了自己不知道对不对。我教你一个自查流程看FROM表名对不对需不需要别名多表连接的条件写了吗看WHERE过滤条件全不全有没有漏掉连接条件导致笛卡尔积看GROUP BYSELECT里非聚合的列是不是都在GROUP BY里看HAVING聚合函数的过滤条件是不是放在这里了看ORDER BY排序字段对不对升序还是降序这个流程走一遍能筛掉80%的低级错误。剩下的20%是逻辑错误比如该用外连接的地方用了内连接该用子查询的地方用了连接。这种就要靠平时多练了。实操心得笔试的时候如果题目没要求优化先写最直观的解法。不要一上来就炫技用窗口函数或递归查询万一写错了连基础分都拿不到。先保证正确再考虑优雅。4.3 面试官追问时的应对策略笔试过了之后面试官经常会拿着你的答案追问。比如你写了一个子查询他会问“这个子查询能改成连接吗为什么”这时候你要能说出两者的区别子查询更直观但连接通常性能更好因为优化器有更多重写空间。但也不是绝对的相关子查询在某些情况下反而更快因为它可以利用索引的过滤能力。再比如你用了NOT IN面试官会问“如果子查询结果里有NULL会怎样”答案是整个查询返回空结果。因为NOT IN (1, 2, NULL)等价于! 1 AND ! 2 AND ! NULL而任何值和NULL比较都是UNKNOWN所以永远不成立。这时候应该用NOT EXISTS或者把NULL排除掉。这种追问环节考的是你的知识边界。你知道就知道不知道就说“这个我平时用得少我的理解是……但不确定对不对”。千万不要硬编面试官一眼就能看出来。5. 从笔试到工作的能力迁移5.1 笔试题目在实际工作中的影子很多人觉得笔试题目脱离实际其实不是。我举几个例子。笔试里常考的“查询每个部门工资最高的员工”在实际工作中就是“查询每个品类销量最高的商品”、“查询每个客户最近一笔订单”。这种分组取Top N的需求在报表系统里天天出现。笔试里常考的“事务隔离级别”在实际工作中就是“为什么我的查询看不到别人刚提交的数据”、“为什么我的更新被阻塞了”。不理解隔离级别遇到并发问题就只能重启数据库。笔试里常考的“索引失效”在实际工作中就是“为什么这个查询昨天还好好的今天突然变慢了”。很多时候就是因为开发在索引列上套了个函数或者传参类型不对导致了隐式转换。所以我的观点是笔试题目不是用来为难你的是用来帮你建立排查问题的思维框架的。你做题的时候多想一步“这个知识点在实际中怎么用”比单纯刷题效果好得多。5.2 建立自己的知识检查清单我建议每个准备Oracle面试的人都建一个自己的检查清单。不用很复杂就按模块列SQL基础SELECT执行顺序、NULL处理、类型转换、CASE WHEN连接内连接、外连接、自连接、交叉连接、连接条件与过滤条件的区别分组GROUP BY规则、HAVING与WHERE、ROLLUP与CUBE子查询相关与非相关、IN与EXISTS、ANY与ALL窗口函数RANK、ROW_NUMBER、LEAD、LAG、SUM OVER事务ACID、隔离级别、锁机制、MVCC索引B树结构、选择率、聚类因子、函数索引、复合索引最左匹配执行计划访问路径、连接方式、成本计算、统计信息每次做题或者面试前过一遍这个清单哪个模块心里没底就重点补。这个方法我用了好几年比漫无目的地刷题效率高得多。5.3 一个容易被忽略的加分项最后说一个很多人忽略的点笔试时的书写规范。SQL关键字大写、缩进对齐、别名有意义、注释清晰。这些细节不会直接加分但会给面试官留下“这个人写代码很规范”的印象。尤其是手写SQL的时候字迹工整、逻辑分层清晰面试官看着舒服可能就多给你几分。我见过一个候选人SQL写得完全正确但所有关键字小写、没有缩进、别名用a、b、c面试官看完说了一句“这代码没法维护”。虽然最后还是给了过但评价明显打了折扣。所以别小看这些细节它们是你专业度的直接体现。实操心得平时练习的时候就用规范格式写考试的时候才不会临时改习惯。我习惯把SELECT、FROM、WHERE、GROUP BY、ORDER BY各占一行缩进用两个空格别名用表名的缩写。这个习惯保持了五六年受益良多。6. 几个我踩过的坑和总结的经验第一个坑过度依赖窗口函数。有段时间我做什么都用ROW_NUMBER()结果有一次面试面试官明确说“不能用窗口函数”我当场卡壳。后来我逼自己用基础语法实现同样的逻辑才发现很多窗口函数的底层就是自连接和分组聚合。这个反向练习让我对SQL的理解深了一大截。第二个坑忽略执行计划。以前做题只看结果对不对不看怎么执行的。后来工作中遇到一个查询逻辑完全正确但跑了半小时一看执行计划发现走了笛卡尔积。从那以后我每写一个复杂SQL都会先EXPLAIN一下看看有没有全表扫描或者嵌套循环过多的问题。第三个坑死记硬背隔离级别。四种隔离级别的定义我背得滚瓜烂熟但面试官问“Oracle默认是哪个为什么”的时候我答不上来。后来才知道Oracle的READ COMMITTED是基于多版本一致性读实现的和标准SQL的定义有差异。这个知识点后来在面试中被问到过三次每次都能拉开差距。最后一个经验把每次笔试当成学习机会。不要做完题对完答案就扔了把错题整理出来找到对应的知识点写一篇自己的理解。我当年准备面试的时候整理了大概五十道错题每道题都写了“考什么、为什么错、正确思路、实际应用”。这份笔记后来成了我面试前唯一的复习资料比任何题库都管用。这个内容后续还可以这样扩展把每道题的实际执行计划跑出来对比不同写法的性能差异或者把题目改造成实际工作场景比如“订单表里查询每个客户最近一笔订单”然后讨论分区表和索引的设计。这些方向都比单纯刷题有意思得多。

相关新闻

Zookeeper在数据治理中的核心应用与优化实践

Zookeeper在数据治理中的核心应用与优化实践

1. Zookeeper与数据治理的天然契合第一次接触Zookeeper是在处理分布式系统的节点协调问题时,这个看似简单的协调服务却让我在处理大数据治理难题时屡建奇功。数据治理本质上是对数据生命周期的管控,而Zookeeper提供的分布式一致性、节点监听和集群管理能…

2026/10/15 13:16:49 阅读更多 →
UVG 4K高帧率测试序列:HEVC/VVC编码器RD曲线与SI/TI筛选实战

UVG 4K高帧率测试序列:HEVC/VVC编码器RD曲线与SI/TI筛选实战

简介:这份资源是面向视频编码研究者、算法工程师及多媒体方向学生的UVG 4K测试视频数据集配套论文,聚焦高帧率超高清序列在编解码分析中的实际需求。数据集由坦佩雷大学Ultra Video Group构建,包含16个4K(38402160)自然…

2026/10/15 13:16:49 阅读更多 →
从目录到展品:prehistoric-animal-museum 内容发现机制 import.meta.glob 深度解析

从目录到展品:prehistoric-animal-museum 内容发现机制 import.meta.glob 深度解析

【免费下载链接】prehistoric-animal-museum A free, open-source bilingual 3D museum where young children and their grown-ups explore prehistoric animals across land, sea, and sky. 项目地址: https://gitcode.com/gh_mirrors/pr/prehistoric-animal-muse…

2026/10/15 13:16:49 阅读更多 →

最新新闻

OpenShell:面向开发者的Windows桌面增强工具

OpenShell:面向开发者的Windows桌面增强工具

1. OpenShell 是什么?它不是 Shell,更不是“开源外壳” OpenShell 这个名字,乍一听容易让人误以为是某种 Linux 或 macOS 的 shell 替代品——比如像 zsh、fish 那样的命令行解释器,或者某个带图形界面的终端模拟器。但事实恰恰相…

2026/10/15 14:31:41 阅读更多 →
OpenShell:跨平台终端环境协同方案详解

OpenShell:跨平台终端环境协同方案详解

1. OpenShell 是什么:一个被严重误读的“跨平台终端体验重构计划”OpenShell 这个名字在当前技术社区里,正经历一场典型的语义漂移——它既不是某个已发布的开源项目官方名称,也不是微软、苹果或Linux发行版的正式组件代号。但恰恰是这种模糊…

2026/10/15 14:31:41 阅读更多 →
FFmpeg转码核心技术解析与实战应用

FFmpeg转码核心技术解析与实战应用

1. 为什么需要系统掌握FFmpeg转码?第一次接触FFmpeg时,我像大多数人一样只会用简单的命令转换视频格式。直到有次客户要求将4K HDR素材转码为适配老旧机顶盒的MPEG-2格式,才发现参数配置不当会导致画质严重劣化。那次经历让我意识到&#xff…

2026/10/15 14:31:41 阅读更多 →
ShardingJDBC分库分表入门:分片键设计、配置实战与生产避坑指南

ShardingJDBC分库分表入门:分片键设计、配置实战与生产避坑指南

这两年总有同事问我,说订单表已经两千多万行了,到底要不要拆表?我的回答通常是:先别急着拆,先想想你的数据访问规律到底是什么。很多人被性能问题逼到分库分表面前,却没搞清楚中间件到底是怎么工作的&#…

2026/10/15 14:31:41 阅读更多 →
Intel SGX入门:硬件级可信执行环境原理与落地实践

Intel SGX入门:硬件级可信执行环境原理与落地实践

1. 从一个真实困惑说起:为什么需要关注SGX我第一次接触Intel SGX是在做一个跨平台数据协作项目的时候。当时的需求很朴素:多个参与方想联合计算一个统计结果,但谁都不愿意把原始数据交出去。我们试过同态加密,性能损耗大到没法接受…

2026/10/15 14:31:41 阅读更多 →
基于 GPU 算力集群利用率的反向限流:防止私有化推理卡池进入热崩溃

基于 GPU 算力集群利用率的反向限流:防止私有化推理卡池进入热崩溃

大模型私有化部署在各行各业落地过程中,绝大多数架构师在传统微服务中积累的限流经验都会彻底失效。传统的 API 网关限流通常基于固定的 QPS 或并发连接数,比如给某个接口配置 200 QPS 的令牌桶。但这套逻辑放在大模型推理集群上几乎等于自杀。 在 LLM 推…

2026/10/15 14:30:40 阅读更多 →

日新闻

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

Docker Compose 容器化部署 ChirpStack LoRaWAN 网络服务器实战

1. 为什么选择容器化方式部署 LoRa 网络服务LoRa 物联网项目落地时,网络服务器是整个链路的核心枢纽。它负责接收网关上报的数据包、完成去重与解密、再把有效载荷分发给上层应用。早期大家习惯把网络服务器直接装在物理机上,依赖一堆系统库和特定版本的…

2026/10/15 0:00:46 阅读更多 →
共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

共享LLM服务下的跨模型自动扩缩容:Kubernetes实战与避坑指南

1. 共享推理服务里,扩缩容到底难在哪做过大模型推理服务部署的人,大概都经历过这样的场景:一个团队共用一套推理集群,A 业务跑的是 7B 的小模型,B 业务跑的是 72B 的大模型,C 业务白天流量高、晚上几乎归零…

2026/10/15 0:00:46 阅读更多 →
Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

Systemd 启动阶段根文件系统只读之谜:fstab 与 remount-fs 服务深度解析

1. 引子:一次内核恐慌引发的追查先从一个真实场景说起。某次我给一台老旧的嵌入式设备折腾系统裁减,为了把启动时间压进两秒以内,我手贱地把一串自认为“没用”的 systemd 服务给 disable 了,其中就包括systemd-remount-fs.servic…

2026/10/15 0:00:46 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/14 16:30:29 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/15 13:48:15 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 0:14:36 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 22:45:47 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/15 9:49:14 阅读更多 →