SQL进阶:掌握WHERE、GROUP BY与HAVING,实现高效数据查询与分析
如果你刚开始学 SQL可能会觉得它很简单——不就是SELECT * FROM table吗但当你真正面对一个业务系统需要从海量数据里快速、准确地找到关键信息或者需要设计一个既能支撑业务增长又易于维护的数据库结构时你会发现SQL 远不止是“查询”那么简单。很多开发者工作几年后依然在写低效、难以维护甚至存在安全隐患的 SQL 语句这直接影响了系统的性能和稳定性。这篇文章我们不谈那些“随着互联网发展”的空话直接解决一个核心问题如何从“能写 SQL”进阶到“会写 SQL”我们将聚焦于 SQL 入门后必须跨越的几个关键门槛数据过滤、结果排序、去重以及最重要的——聚合函数。这些是构建任何复杂查询和分析的基石也是面试和实际工作中区分新手与熟手的分水岭。读完本文你将能清晰地写出高效、精准的查询语句并理解其背后的执行逻辑而不仅仅是记住语法。1. 这篇文章真正要解决的问题很多 SQL 教程停留在基础语法的罗列导致学习者虽然知道WHERE、ORDER BY怎么用却不清楚为什么我的查询这么慢尤其是在数据量稍大时。如何精确地筛选出我需要的“那部分”数据而不是先SELECT *再在代码里过滤。如何对数据进行有意义的统计和摘要比如计算销售总额、平均客单价、每月新增用户数。如何避免查询结果中出现重复或无意义的杂乱数据本文将围绕WHERE条件过滤、ORDER BY结果排序、DISTINCT去重和聚合函数COUNT,SUM,AVG,MAX,MIN,GROUP BY展开。我们的目标不是让你记住另一个语法列表而是通过场景和对比让你理解WHERE和HAVING的本质区别是什么为什么聚合后的条件过滤必须用HAVINGGROUP BY到底在做什么它是如何改变查询结果集的如何组合这些子句写出一个逻辑清晰、执行高效的完整查询如果你正在做数据分析、后端开发、测试或者任何需要与数据库打交道的岗位掌握这些内容是摆脱“SQL 小白”标签的关键一步。2. 核心概念从“取数据”到“分析数据”在深入语法之前我们需要建立两个重要的认知模型1. SQL 语句的执行顺序与书写顺序不同。这是理解复杂查询的关键。你写的顺序是SELECT column1, aggregate(column2) FROM table WHERE condition GROUP BY column1 HAVING aggregate_condition ORDER BY column1 LIMIT n;但数据库引擎理解大致的顺序是FROM: 确定数据来源。WHERE: 对原始数据行进行过滤。GROUP BY: 将过滤后的数据分组。HAVING: 对分组后的结果集进行过滤。SELECT: 选择要显示的列或计算聚合值。ORDER BY: 对最终结果集排序。LIMIT: 限制返回的行数。WHERE在分组前过滤行HAVING在分组后过滤组这是最核心的区别。2. 聚合函数的本质是“降维”计算。想象一张详细的订单表每一行代表一件商品的购买记录。SUM(amount)并不是简单地把一列数字加起来它隐含了一个动作将多行数据明细聚合成一个更有意义的统计值摘要。GROUP BY就是这个聚合过程的“分组依据”。没有GROUP BY聚合函数会将整个表视为一组有了GROUP BY就会按指定列分成多个组分别在每个组内进行聚合。理解了这两点再看具体的语法就不会感到混乱。3. 环境准备使用在线沙箱快速实践为了确保大家能同步实践我们不需要安装复杂的 MySQL 或 SQL Server。推荐使用完全免费的在线 SQL 练习平台SQL Fiddle( http://sqlfiddle.com/ ) 或DB Fiddle( https://www.db-fiddle.com/ )。我们以 DB Fiddle 为例选择 MySQL 8.0 作为数据库。以下是本文所有示例将使用的测试表和数据你可以直接复制到 DB Fiddle 的左侧“Schema”面板中执行。-- 创建示例数据库和表 CREATE DATABASE IF NOT EXISTS sales_db; USE sales_db; -- 创建员工表 DROP TABLE IF EXISTS employees; CREATE TABLE employees ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, department VARCHAR(50), salary DECIMAL(10, 2), hire_date DATE ); -- 创建销售订单表 DROP TABLE IF EXISTS sales_orders; CREATE TABLE sales_orders ( order_id INT PRIMARY KEY AUTO_INCREMENT, employee_id INT, customer_name VARCHAR(50), product_category VARCHAR(50), amount DECIMAL(10, 2), order_date DATE, FOREIGN KEY (employee_id) REFERENCES employees(id) ); -- 插入员工数据 INSERT INTO employees (name, department, salary, hire_date) VALUES (张三, 技术部, 15000.00, 2021-03-15), (李四, 技术部, 18000.00, 2020-07-22), (王五, 销售部, 12000.00, 2022-01-10), (赵六, 销售部, 10000.00, 2022-11-30), (钱七, 市场部, 13000.00, 2021-09-05), (孙八, 技术部, 16000.00, 2019-12-01); -- 插入销售订单数据 INSERT INTO sales_orders (employee_id, customer_name, product_category, amount, order_date) VALUES (3, 客户A, 电子产品, 2999.00, 2023-10-01), (3, 客户B, 办公用品, 450.50, 2023-10-05), (4, 客户C, 电子产品, 5200.00, 2023-10-02), (3, 客户A, 家具, 3200.00, 2023-10-08), (5, 客户D, 办公用品, 120.00, 2023-10-03), (4, 客户E, 电子产品, 1500.00, 2023-10-10), (3, 客户F, 家具, 2800.00, 2023-10-15), (5, 客户G, 办公用品, 650.80, 2023-10-12), (4, 客户H, 电子产品, 4300.00, 2023-10-20), (3, 客户A, 电子产品, 2100.00, 2023-10-25);执行成功后你可以在右侧“Query”面板开始我们的练习。4. 精准过滤WHERE 子句的进阶用法WHERE是限制结果集的第一步也是影响查询性能的关键。基础的、、不再赘述我们看几个容易出错或忽略的实用场景。4.1 处理 NULL 值一个常见的陷阱NULL 表示“未知”或“缺失”它不等于任何值甚至不等于它自己。用或!判断 NULL 是无效的。错误示例-- 试图找出没有部门的员工错误写法 SELECT * FROM employees WHERE department NULL; -- 不会有任何结果 SELECT * FROM employees WHERE department ! NULL; -- 同样不会有结果正确方法使用IS NULL或IS NOT NULL。-- 找出没有部门的员工 SELECT * FROM employees WHERE department IS NULL; -- 找出有部门的员工 SELECT * FROM employees WHERE department IS NOT NULL;4.2 范围与集合查询IN 和 BETWEEN当条件是一个明确的列表或一个连续区间时IN和BETWEEN比多个OR更清晰、有时也更高效。-- 查找特定部门的员工使用多个 OR SELECT * FROM employees WHERE department 技术部 OR department 市场部; -- 更清晰的写法使用 IN SELECT * FROM employees WHERE department IN (技术部, 市场部); -- 查找薪资在某个区间的员工 SELECT * FROM employees WHERE salary 12000 AND salary 16000; -- 等价且更语义化的写法 SELECT * FROM employees WHERE salary BETWEEN 12000 AND 16000; -- 注意BETWEEN 是包含端点的IN的优势当列表很长时IN子句的解析通常比一长串OR更快并且写法简洁。4.3 模糊匹配LIKE 与通配符用于搜索文本字段中的模式。最常用的通配符是%匹配任意数量包括零个的任意字符。_匹配单个任意字符。-- 查找姓‘张’的员工 SELECT * FROM employees WHERE name LIKE 张%; -- 查找名字中带‘三’的员工 SELECT * FROM employees WHERE name LIKE %三%; -- 查找名字为三个字且第二个字是‘七’的员工此例中没有 SELECT * FROM employees WHERE name LIKE _七_;性能提示以%开头的LIKE查询如LIKE ‘%三’通常无法有效利用索引会导致全表扫描在大数据表上慎用。5. 控制结果呈现ORDER BY 与 DISTINCT查询出来的数据如何让人一目了然5.1 ORDER BY给结果排序默认是升序ASC降序需要用DESC。可以按多个列排序。-- 按薪资从高到低排序 SELECT name, department, salary FROM employees ORDER BY salary DESC; -- 先按部门升序排列部门相同的再按薪资降序排列 SELECT name, department, salary FROM employees ORDER BY department ASC, salary DESC;5.2 DISTINCT消除重复行用于返回唯一不同的值。注意它是基于SELECT后面所有列的组合来判断是否重复。-- 查看公司有哪些不同的部门 SELECT DISTINCT department FROM employees; -- 查看员工所在的部门-薪资组合有哪些注意这里同部门不同薪资算不同组合 SELECT DISTINCT department, salary FROM employees ORDER BY department;一个常见的误解DISTINCT不是函数不能写成DISTINCT(department)虽然有些数据库允许但标准写法是SELECT DISTINCT department。6. 数据聚合的核心GROUP BY 与聚合函数这是从“查询数据”到“分析数据”的飞跃。我们通过一个业务问题来学习“统计每个销售部门的员工人数和平均薪资”。6.1 聚合函数速览函数说明忽略 NULL 值吗COUNT()计数行数。COUNT(*)计数所有行COUNT(column)计数该列非 NULL 的行。COUNT(column)忽略 NULLSUM()对数值列求和。是AVG()对数值列求平均值。是MAX()求最大值。是MIN()求最小值。是6.2 GROUP BY 的基本使用GROUP BY子句将结果集按一列或多列分组然后聚合函数在每个组内分别计算。-- 统计每个部门的员工人数和平均薪资 SELECT department, COUNT(*) AS employee_count, -- 使用 COUNT(*) 计算每个部门的行数人数 AVG(salary) AS avg_salary FROM employees WHERE department IS NOT NULL -- 先过滤掉无部门的员工 GROUP BY department; -- 按部门分组执行结果预览departmentemployee_countavg_salary技术部316333.333333市场部113000.000000销售部211000.000000关键理解FROM employees从员工表取数据。WHERE department IS NOT NULL过滤掉部门为 NULL 的行。此时还没有分组。GROUP BY department将过滤后的行按照department的值分成不同的组技术部组、市场部组、销售部组。SELECT ...对于每一组计算该组的COUNT(*)和AVG(salary)并选出department列由于按它分组每组只有一个值。6.3 SELECT 列表的规则为什么有些列不能直接选在包含GROUP BY的查询中SELECT列表中只能出现两种列出现在GROUP BY子句中的列。被聚合函数包裹的列。错误示例-- 错误name 列既不在 GROUP BY 中也没有被聚合 SELECT department, name, AVG(salary) FROM employees GROUP BY department;执行会报错因为在一个“销售部”组里有“王五”和“赵六”两个name数据库不知道应该输出哪一个。你必须通过聚合函数来明确意图例如GROUP_CONCAT(name)把名字拼接起来或者干脆不选择name列。7. 对分组结果进行过滤HAVING 子句WHERE在分组前过滤行HAVING在分组后过滤组。HAVING的条件通常涉及聚合函数。业务场景在上一个查询基础上我们只想看平均薪资超过 12000 的部门。SELECT department, COUNT(*) AS employee_count, AVG(salary) AS avg_salary FROM employees WHERE department IS NOT NULL GROUP BY department HAVING AVG(salary) 12000; -- 对分组后的聚合结果进行过滤执行结果departmentemployee_countavg_salary技术部316333.333333市场部113000.000000可以看到“销售部”因为平均薪资 11000 不满足HAVING条件被过滤掉了。WHEREvsHAVING对比表特性WHEREHAVING作用时机在GROUP BY之前对原始数据行过滤。在GROUP BY之后对分组聚合后的结果过滤。可用的条件可以使用表中的任意列但不能直接使用聚合函数。通常使用聚合函数的结果作为条件也可以使用GROUP BY的列。性能影响先过滤可以减少分组处理的数据量性能更好。对已分组聚合的数据过滤。典型用途排除不需要参与计算的行。如WHERE order_date ‘2023-01-01’。筛选出符合条件的分组。如HAVING SUM(amount) 10000。8. 完整实战一个复杂的业务分析查询让我们结合所有知识点完成一个更贴近实战的复杂查询。业务需求分析2023年10月份的销售情况。统计每个销售员employee_id的业绩。业绩指标包括订单总数、总销售额、平均订单金额。只考虑‘电子产品’和‘家具’这两个品类。仅展示总销售额超过5000元的销售员。结果按总销售额从高到低排序。SELECT e.name AS salesperson_name, COUNT(so.order_id) AS total_orders, SUM(so.amount) AS total_sales_amount, AVG(so.amount) AS avg_order_amount FROM sales_orders so JOIN employees e ON so.employee_id e.id -- 关联员工表获取销售员姓名 WHERE so.product_category IN (‘电子产品‘ ’家具‘) -- 条件1筛选品类 AND so.order_date ‘2023-10-01‘ AND so.order_date ‘2023-10-31‘ -- 条件2筛选时间 AND e.department ‘销售部‘ -- 条件3确保是销售部员工 GROUP BY so.employee_id, e.name -- 按销售员分组 HAVING SUM(so.amount) 5000 -- 条件4过滤分组结果 ORDER BY total_sales_amount DESC; -- 条件5排序语句拆解分析FROM JOIN: 从sales_orders表别名so和employees表别名e关联开始通过employee_id关联确保我们能拿到销售员的名字。WHERE: 在分组前应用三个过滤条件大幅减少后续需要处理的数据量。这是优化查询性能的关键步骤。GROUP BY: 按销售员 (so.employee_id) 和其姓名 (e.name) 分组。理论上按employee_id分组即可但为了在SELECT中能直接显示name最好一起放入GROUP BY。HAVING: 分组聚合后只保留总销售额 (SUM(so.amount)) 大于 5000 的分组。SELECT: 计算每个分组即每个销售员的订单数、销售总额和平均订单额。ORDER BY: 对最终结果按销售总额降序排列。这个查询完整地展示了WHERE、JOIN、GROUP BY、HAVING、ORDER BY以及别名 (AS) 的综合运用。9. 常见问题与排查思路问题现象可能原因排查方式解决方案查询结果为空但确信有数据1.WHERE条件过于严格或错误。2. 涉及NULL的条件使用了或!。3.JOIN条件不匹配导致数据被过滤。1. 逐步简化WHERE条件或先SELECT *查看所有数据。2. 检查对可能为NULL的列是否误用了。3. 尝试使用LEFT JOIN查看主表所有数据。1. 复核业务逻辑和条件表达式。2. 将column NULL改为column IS NULL。3. 检查关联键的数据一致性和类型。报错“Column ‘xxx’ in SELECT list is not in GROUP BY clause”SELECT列表中包含了既未分组也未被聚合的列。仔细检查SELECT后的每一列。1. 将该列添加到GROUP BY子句中。2. 使用聚合函数处理该列如MAX,MIN,GROUP_CONCAT。3. 从SELECT列表中移除该列。HAVING子句报错或结果不对在HAVING中使用了未在SELECT中聚合的列或条件逻辑错误。确认HAVING中的条件表达式引用的是聚合函数结果或GROUP BY列。确保HAVING条件中的列要么被聚合要么在GROUP BY中。使用聚合函数别名可能更清晰。查询速度非常慢1. 表数据量大。2.WHERE条件中的列没有索引。3. 使用了LIKE ‘%xxx’这种无法利用索引的模糊查询。4. 不必要地使用了SELECT *。1. 使用EXPLAIN命令分析查询执行计划。2. 查看慢查询日志。1. 为WHERE、JOIN、ORDER BY涉及的列添加索引。2. 避免前导通配符%。3. 只SELECT需要的列。4. 优化WHERE条件尽早过滤数据。COUNT结果不符合预期使用了COUNT(column)而非COUNT(*)而该列存在NULL值。确认业务需求是统计所有行数还是统计某列非 NULL 的行数COUNT(*)计数所有行。COUNT(column)计数该列非 NULL 的行。根据需求选择。10. 最佳实践与工程建议始终指定列名避免SELECT *在生产环境或复杂查询中SELECT *会带来额外开销网络传输、内存占用并且当表结构变更时你的应用程序可能会意外中断。明确列出所需列是良好的习惯。-- 不推荐 SELECT * FROM employees WHERE ...; -- 推荐 SELECT id, name, department FROM employees WHERE ...;为WHERE、JOIN、ORDER BY的列建立索引这是提升查询性能最有效的手段之一。尤其是当表数据量增长到十万、百万级时没有索引的过滤和排序操作会变得极其缓慢。善用别名AS让查询更易读对于复杂的表名、列名或计算字段使用别名可以大大提高 SQL 语句的可读性和可维护性。SELECT e.name AS employee_name, d.name AS department_name, SUM(s.amount) AS total_sales FROM ...先过滤后聚合尽量在WHERE子句中完成所有可能的数据过滤减少进入GROUP BY阶段的数据量。HAVING只应用于必须依赖聚合结果才能进行的过滤。理解业务逻辑再写 SQL在动手写复杂查询前先用自然语言或注释把业务逻辑描述清楚。例如“我要找2023年第三季度来自‘华东’地区购买金额超过1000元的所有客户并按购买总额排序。” 这能帮你理清WHERE、GROUP BY、HAVING、ORDER BY的先后关系。在测试环境验证结果对于重要的数据统计或更新查询务必先在测试环境或使用SELECT预览结果确认逻辑正确后再正式执行。对于UPDATE和DELETE操作可以先将其改为SELECT语句来检查会影响哪些行。从能写出返回结果的 SQL到能写出高效、准确、易维护的 SQL中间差的就是对这些核心子句的深刻理解和大量实践。WHERE、GROUP BY、HAVING、ORDER BY的组合构成了 SQL 进行数据分析和业务洞察的骨架。记住执行顺序FROM→WHERE→GROUP BY→HAVING→SELECT→ORDER BY并在每次写复杂查询时心里默念一遍能帮你避免大多数逻辑错误。下一步你可以尝试挑战更复杂的多表连接JOIN查询、子查询以及窗口函数这些将让你处理数据的能力再上一个台阶。建议把本文的示例在 DB Fiddle 中逐一运行和修改直到你能不参考文档独立写出满足复杂业务需求的统计查询。

相关新闻

网红藏餐推荐哪家朋友推荐多

网红藏餐推荐哪家朋友推荐多

来拉萨旅游,吃饭绝对是头等大事。打开小红书、抖音,满屏都是“必打卡藏餐”推荐,但等你真正走进去,才发现十有八九踩了雷——要么环境嘈杂得像菜市场,要么菜品油腻到怀疑人生,更别提那些用料理包糊弄人的“…

2026/10/17 9:51:17 阅读更多 →
2026 上海先进制造业 GEO 服务商适配度榜单报告

2026 上海先进制造业 GEO 服务商适配度榜单报告

当采购工程师在 AI 平台输入 “临港新能源汽车精密结构件供应商”“嘉定高端医疗器械加工厂商”,AI 输出的优先推荐清单,正在直接改写上海制造企业的订单格局。不少上海专精特新制造企业,拥有成熟产线、完备资质、过硬工艺,却在豆…

2026/10/17 10:28:46 阅读更多 →
告别 Tushare/AkShare 数据清洗地狱:统一沪深京美港代码后缀的最佳量化实践

告别 Tushare/AkShare 数据清洗地狱:统一沪深京美港代码后缀的最佳量化实践

📌 摘要 / 快速解答 (Direct Answer) Tushare 与 AkShare 等传统数据源在跨市场(沪/深/京/美/港)代码规范上存在巨大差异,如 600519.SH vs sh600519 vs 600519 等格式混乱,导致开发者需要编写大量正则表达式与适配映射…

2026/10/17 10:28:27 阅读更多 →

最新新闻

在线考试系统的Java后端设计:并发、判分与数据一致性避坑指南

在线考试系统的Java后端设计:并发、判分与数据一致性避坑指南

简介:一套面向Java学习者和毕业设计开发的在线考试管理系统完整交付包,涵盖源代码、论文、开题报告、外文翻译、英文文献与答辩PPT,适合快速搭建在线考试项目或完成课程设计、毕业设计汇报。系统覆盖题库管理、考试安排、在线答题、自动评分和…

2026/10/18 9:57:37 阅读更多 →
大模型推理优化实战:从KV Cache到量化与调度的完整路线

大模型推理优化实战:从KV Cache到量化与调度的完整路线

做推理优化这一行,最常被问的一句话是:同一个模型,为什么别人能拉满吞吐、压住延迟,我这边一上线就 OOM,用户稍微一多,首字延迟直接飙到十几秒?这类问题问多了你会发现,大模型推理优…

2026/10/18 9:57:37 阅读更多 →
计算机网络核心考点:TCP握手、DNS解析与HTTP演进全解析

计算机网络核心考点:TCP握手、DNS解析与HTTP演进全解析

简介:这份PDF面向程序员与求职者,是计算机基础面试核心考点的精华合集,尤其聚焦计算机网络高频问题。内容系统梳理了TCP三次握手与四次挥手、HTTP与HTTPS的区别、HTTP缓存机制、DNS域名解析层级与递归/迭代查询,并详细拆解在浏览器…

2026/10/18 9:57:37 阅读更多 →
Agent基础设施(Agent Infra)四层架构与落地实践

Agent基础设施(Agent Infra)四层架构与落地实践

1. “Agent Infra”不是新概念,而是旧问题在新尺度上的总爆发“Agent Infra”这个词最近在技术圈高频闪现,但你翻遍主流文档、RFC草案甚至大厂开源仓库的README,几乎找不到一个被明确定义的官方术语。它不像Kubernetes或React那样有清晰的边界…

2026/10/18 9:57:37 阅读更多 →
C#台达AS228 PLC上位机模板:自动运行与手动调试全覆盖

C#台达AS228 PLC上位机模板:自动运行与手动调试全覆盖

C#台达AS228主机PLC上位机模板程序:功能齐全,自动运行与手动调试搞工控开发的朋友应该都有体会,一套好用的上位机模板能省掉大量重复性工作。我手里这套基于C#和台达AS228 PLC的上位机程序,就是我在多个项目里反复打磨出来的产物。…

2026/10/18 9:57:37 阅读更多 →
计算机基础面试:URL全流程、三次握手与HTTP演进要点

计算机基础面试:URL全流程、三次握手与HTTP演进要点

简介:这是一份面向程序员求职与面试准备的计算机网络基础知识点PDF资料,尤其适合准备后端、前端岗位笔试面试的求职者,用于快速补齐高频考点。内容取自代码随想录知识星球精华(最强八股文)第五版计算机基础篇&#xff…

2026/10/18 9:56:37 阅读更多 →

日新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/18 0:00:55 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/18 0:00:55 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/18 0:00:55 阅读更多 →

周新闻

基于GMM的语音识别系统原理与MATLAB实现详解

基于GMM的语音识别系统原理与MATLAB实现详解

说到基于高斯混合模型(GMM)的语音识别系统,很多人第一反应就是一堆数学公式,觉得门槛很高。但如果你真的在MATLAB里把它落地跑通,会发现核心其实就是三件事:把声音变成特征向量,用GMM给每个类别…

2026/10/18 0:00:55 阅读更多 →
数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理入门:反白、灰度化、调色板修改与导出txt实践

数字图像处理这四个字听起来挺唬人,但落到具体操作上,无非就是让计算机按你的想法“摆弄”像素。我在一个模拟项目X里用了一套特别经典的基础处理流程:对图像做反白、改调色板、彩色转灰度,最后把像素数据导出成txt文件。单看每一…

2026/10/18 0:00:55 阅读更多 →
机器人大脑技术盘点:具身智能的感知、决策与数据闭环

机器人大脑技术盘点:具身智能的感知、决策与数据闭环

如果你的信息流最近也天天刷到“机器人大脑”这个词,你会发现一个很有意思的现象:每个人说的“大脑”根本不是同一个东西。有人指的是大语言模型,有人指的是运动控制系统,还有人指的是能理解物理世界的端到端模型。在2026年这个时…

2026/10/18 0:00:55 阅读更多 →

月新闻

我发现了一个新思路:用 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/18 0:55:02 阅读更多 →
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/17 17:22:31 阅读更多 →
黑夜航拍船只数据集训练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/16 14:23:36 阅读更多 →