REECHO大鱼总舵查了好几年SQL相关的资料，各种论坛帖子翻了个遍，笔记本上密密麻麻记了几十页。今天正好有时间，我把这些零散的笔记重新整理了一遍，去掉那些过时的、错误的，留下真正用得上的东西。这份笔记覆盖了从基础语法到慢SQL优化、从日常工具到安全防护的内容，适合刚入门的学生、写业务代码但SQL总是写不顺的开发，以及被线上慢查询折磨的运维同学。看完不能说成为专家，但起码日常开发遇到的绝大多数问题都能找到思路。
1. SQL的基本功：先弄清楚执行顺序，再谈写SQL
1.1 为什么SQL看着简单却总出错
很多新手觉得SQL简单，无非就是SELECT、FROM、WHERE、GROUP BY这些关键词拼在一起。但真到写复杂查询的时候，不是结果不对，就是慢得离谱，根本原因多数时候是没搞清楚SQL的执行逻辑顺序。
我见过太多人以为SQL是从SELECT开始执行的，这是最大的误区。实际上，SQL的执行顺序和书写顺序完全不同：
- FROM：先确定从哪张表取数
- JOIN：关联需要的表
- WHERE：过滤行级别的条件
- GROUP BY：分组
- HAVING：过滤分组后的结果
- SELECT：投影需要的列
- ORDER BY：排序
- LIMIT/OFFSET：分页
举个例子，很多人会困惑为什么WHERE里面不能用SELECT里的别名，比如 SELECT name AS n FROM users WHERE n = '张三' 报错。就是因为WHERE执行在SELECT之前，此时别名还不存在，数据库压根不知道n是什么。这个道理想通了，就能解释很多所谓“奇怪”的报错。
另外，执行顺序也是理解性能问题的钥匙。WHERE在GROUP BY之前执行，意味着能在WHERE阶段过滤掉的数据，就不要拖到GROUP BY之后。这些都是SQL优化的底层逻辑，后面我会细讲。
1.2 AND和OR混在一起时谁说了算
这个坑我踩过不止一次，而且是在看别人代码的时候发现的。SQL里同时出现AND和OR的时候，AND的优先级高于OR。也就是说，A AND B OR C 实际被解析成 (A AND B) OR C，而不是很多人以为的 A AND (B OR C)。
举个例子，想查“VIP用户或者最近7天登录过的用户，而且必须是状态正常的”：
sql复制SELECT * FROM users WHERE status = 1 AND is_vip = 1 OR last_login > DATE_SUB(NOW(), INTERVAL 7 DAY);
这段SQL的结果会把“最近7天登录过但状态不正常”的用户也查出来，因为OR的优先级低，整个条件变成了“状态正常且是VIP”或“最近7天登录过”。正确的写法是：
sql复制SELECT * FROM users WHERE status = 1 AND (is_vip = 1 OR last_login > DATE_SUB(NOW(), INTERVAL 7 DAY));
我自己现在的习惯是：只要WHERE条件里同时出现AND和OR，不管逻辑多简单，一律加括号。不要考验自己几个月后读代码时的记忆力和耐心，括号一加，意图清清楚楚。
1.3 WHERE和HAVING的边界感
WHERE和HAVING都能过滤数据，但两者有本质区别。WHERE是行级过滤，发生在分组之前；HAVING是组级过滤，发生在分组之后，而且只能和GROUP BY配合使用。
我曾经犯过一个错误，想查订单总额超过10000的客户，写了这样的SQL：
sql复制SELECT customer_id, SUM(amount) AS total FROM orders WHERE SUM(amount) > 10000 GROUP BY customer_id;
直接报错，因为WHERE无法识别聚合函数。正确写法是：
sql复制SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id HAVING SUM(amount) > 10000;
理解了这个区别，还得明白性能上的差异。能在WHERE里过滤掉的记录，就不要等到HAVING里通过聚合后的结果来过滤，因为WHERE可以减少进入GROUP BY阶段的数据量，而HAVING要等分组计算完成后才过滤。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 写好SQL的日常习惯
2.1 去重查询：DISTINCT和GROUP BY的取舍
去重是日常开发最高频的需求之一。最简单的是用DISTINCT，但很多人不知道DISTINCT和GROUP BY在功能和性能上的差别。
DISTINCT本质上是把所有返回列作为分组键做去重，而GROUP BY可以只指定部分列为分组键。比如查一个表里有多少个不同的城市：
sql复制SELECT DISTINCT city FROM users;
如果需求是查每个城市的用户数，DISTINCT就做不了了，得用GROUP BY：
sql复制SELECT city, COUNT(*) FROM users GROUP BY city;
这里有个容易搞混的点：有些人想“去重”的时候，其实想要的是“每个分组取一条记录”。比如每个用户取最新一条订单，这种场景DISTINCT和GROUP BY都不太好使，需要用窗口函数：
sql复制SELECT * FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders
) t WHERE rn = 1;
每次写这种SQL的时候我都会想，如果能早点学会窗口函数，当年也不会用那么多种奇奇怪怪的写法来实现“取分组内最新一条”的需求了。如果你还在用旧版本MySQL，可能没有窗口函数，那就只能用相关子查询或者GROUP BY + JOIN绕一下，但逻辑远没有窗口函数清晰。
2.2 NULL值的坑：不是你想的那样
NULL可能是SQL里最反直觉的东西。它既不是0，也不是空字符串，而是“未知”的意思。所以任何和NULL做比较的结果都是NULL，不是TRUE也不是FALSE。
最常见的坑是：想查某个字段为空的记录，写了 WHERE name = NULL，结果一条都查不出来。正确写法是：
sql复制SELECT * FROM users WHERE name IS NULL;
还有一个坑是COUNT。COUNT(*) 统计的是所有行数，而 COUNT(column) 统计的是该列非NULL的行数。很多人在统计订单量的时候用了 COUNT(order_id)，但某条记录order_id是NULL的，结果数字对不上，排查半天才发现问题。
处理NULL还有个实用函数COALESCE，它接受多个参数，返回第一个非NULL的值。比如查用户表，手机号和邮箱可能只填了一个，想统一展示：
sql复制SELECT COALESCE(phone, email, '未填写') AS contact FROM users;
每次写SQL之前，先想想哪些字段可能为NULL，这能帮你避免一大半莫名其妙的“数据对不上”问题。
2.3 BETWEEN AND的边界问题
BETWEEN AND用起来很舒服，但它包含边界值，也就是闭区间。BETWEEN 1 AND 10 等价于 >= 1 AND <= 10。这个特性在处理日期的时候特别容易出问题。
比如查2024年1月的订单，写了：
sql复制SELECT * FROM orders WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31';
如果order_date是datetime类型，那么1月31日当天的订单不会全部查出来，因为 '2024-01-31' 会被转换成 '2024-01-31 00:00:00'，而当天其他时间的数据都被过滤掉了。
解决这个经典问题有两种思路：一种是改写成 >= '2024-01-01' AND < '2024-02-01'，这种半开区间写法是我最推荐的，逻辑清晰且不会漏数据；另一种是用DATE函数把日期截断，但那样会导致索引失效，影响性能，属于下策。
2.4 WITH AS：把复杂查询拆成人能读懂的段落
很多复杂的SQL动辄几十行，嵌套好几层子查询，读起来像天书。WITH AS（也叫公共表表达式，CTE）能把大查询拆成一个个有名字的段落，每个段落单独看都很清晰。
比如查“连续三天有消费记录的用户”，直接写子查询会非常痛苦，用CTE就清晰得多：
sql复制WITH daily_orders AS (
SELECT user_id, DATE(created_at) AS order_date, COUNT(*) AS cnt
FROM orders
GROUP BY user_id, DATE(created_at)
),
ranked AS (
SELECT user_id, order_date,
LAG(order_date, 2) OVER (PARTITION BY user_id ORDER BY order_date) AS prev_2
FROM daily_orders
)
SELECT DISTINCT user_id FROM ranked WHERE prev_2 IS NOT NULL;
CTE还有一个额外的好处：在部分数据库里，同一个CTE被多次引用时只需要执行一次，能提升查询效率。不过MySQL 8.0之前的版本不支持CTE，如果还在用老版本，可以考虑升级或者改写成派生表。
3. 工具链与实操：从安装到导入SQL文件
3.1 SQL Server安装避坑指南
热搜词里好几个都是关于SQL Server安装的，说明这个坑确实不少。我装过2019和2022，说一下关键点。
首先，SQL Server 2022安装过程中最容易出问题的是“防火墙”和“服务账户”两步。安装时如果勾选了“给SQL Server启用防火墙规则”，一般不会有大问题，但如果你自定义了端口实例或者改了默认规则，远程连接就很容易失败。
第二个常见问题是安装完成后，本地连接正常，但远程连接提示用户登录失败。这个几乎都是身份验证模式设置问题。默认安装是Windows身份验证模式，要用sa登录或远程连接，必须在安装时或者安装后用SQL Server Management Studio把“服务器身份验证”改成“SQL Server和Windows身份验证模式”，并启用sa账户、设置密码。
我遇到过一个人，改了身份验证模式之后还是报 [28000] [microsoft][odbc driver 17 for sql server][sql server]用户 'sa' 登录失败。排查了半天，发现是sa账户被禁用了。在SSMS里右键sa账户，把“登录”状态改为“启用”，再重新设置一下密码就好了。另外，如果用的是ODBC驱动，还要确保驱动版本和SQL Server版本兼容，ODBC Driver 17连SQL Server 2022基本没问题，但有些老应用用的是旧版驱动，就会出现“未找到数据源名称”之类的报错。
还有个小技巧：SSMS里默认不显示行号，排查存储过程报错的时候特别痛苦。在“工具 -> 选项 -> 文本编辑器 -> 所有语言 -> 常规”里面勾选“行号”，就能在代码编辑器里看到行号了，错误定位的效率能提升不少。
3.2 导入SQL文件的多种姿势
日常工作中经常要导入SQL文件，不管是恢复备份、初始化数据还是迁移环境。说几个工具的体验。
DBeaver是目前我用的最多的数据库客户端。导入SQL文件的方法是：连接到目标数据库，打开SQL编辑器，然后用“打开文件”或者直接拖拽SQL文件进去，再点击执行。如果文件特别大，比如几百MB，DBeaver会卡得比较厉害，这种情况不建议用DBeaver，建议用命令行或者HeidiSQL。
HeidiSQL是我在Windows上用过的另一款工具，轻量、启动快。导入SQL文件很简单：右键数据库，选择“运行SQL文件”，选择文件后点开始。HeidiSQL的导入速度比DBeaver快不少，大文件也不容易内存溢出。
如果是MySQL，最稳的还是命令行：
bash复制mysql -u root -p mydatabase < /path/to/file.sql
导入的时候有两个细节容易踩坑。一是字符集，如果SQL文件里包含了中文，而文件编码和数据库字符集不一致，导入后中文全是乱码。建议导入前先确认SQL文件的编码是UTF-8（含BOM可能会导致第一条SQL报错），并且数据库、表、连接三者的字符集保持一致。二是有时候SQL文件里包含了USE database的语句，如果文件里指定的数据库名和本地不一致，导入后数据会跑到别的库里去。导入前先看一眼文件开头有没有USE语句。
3.3 SQL代码排版，为什么值得花时间
热搜词里有“SQL代码排版工具”，这个看起来不起眼，但我觉得非常值得说一下。很多开发同学觉得SQL格式无所谓，能跑就行。但实际在做代码评审的时候，一段排版混乱的SQL真的很难让人读懂逻辑，出了Bug也不容易定位。
好的排版习惯包括：关键字统一大写或小写（我习惯大写，一眼能看清结构）；每行一个字段；JOIN条件缩进；WHERE条件按逻辑分组。
比如这段：
sql复制SELECT a.id, a.name, b.total FROM orders a JOIN users b ON a.user_id=b.id WHERE a.status=1 AND b.level=2 GROUP BY a.id, a.name, b.total HAVING b.total>100 ORDER BY b.total DESC;
改成：
sql复制SELECT a.id, a.name, b.total
FROM orders a
JOIN users b ON a.user_id = b.id
WHERE a.status = 1
AND b.level = 2
GROUP BY a.id, a.name, b.total
HAVING b.total > 100
ORDER BY b.total DESC;
如果是手动排版，效率确实低。现在很多IDE（比如DataGrip、DBeaver）都有SQL格式化快捷键，也有在线格式化工具，复制进去一秒排版好。我的建议是：格式化不是可有可无的洁癖，而是降低沟通成本、减少低级错误的方式。尤其给别人看代码的时候，一个规整的SQL给人的信任感是完全不一样的。
3.4 PL/SQL和MyBatis动态SQL：写程序里的SQL又不一样
开发场景下，写SQL的姿势通常有两种：一种是在数据库的过程化语言里写，比如Oracle的PL/SQL；另一种是在代码里拼SQL，比如Java的MyBatis。
PL/SQL和纯SQL最大的区别是它有自己的编程结构：变量、循环、异常处理。我早年用PL/SQL写过不少批量数据处理脚本，感觉最需要注意的是事务控制和异常捕获。不要在一个大事务里处理几十万条数据，万一中间报错，回滚起来非常痛苦。我的做法是分批提交，每处理1000条COMMIT一次，既能保证进度可控，又不会一直持有锁。
MyBatis的动态SQL就是另一回事了。它最大的坑是SQL注入的风险，因为动态SQL经常需要拼接条件。MyBatis的 <if>、<where> 标签虽然好用，但如果不小心写了 ${} 而不是 #{}，等于把SQL注入的大门给打开了。${} 是字符串替换，直接拼进SQL；#{} 是预编译参数占位符，会转成 ? 再绑定值。能用 #{} 的地方不用 ${}，这是铁律。
MyBatis还有一个常见问题：动态SQL写多了以后XML可读性很差。我的经验是，一个SQL文件里别堆太多复杂的动态条件，超过三四个 <if> 就该考虑拆分成多个方法，或者用注解的方式简化结构。
4. SQL注入：开发必须知道的安全底线
4.1 万能密码绕过的原理
“sql注入万能密码绕过”这个热搜词一看就是网络安全相关的。SQL注入的原理说穿了很简单：应用程序把用户输入直接拼接到SQL语句中，用户输入的特殊字符改变了SQL的原本逻辑。
经典的万能密码绕过，比如登录功能里的SQL是：
sql复制SELECT * FROM users WHERE username = 'admin' AND password = '123456';
如果代码是字符串拼接的方式：
java复制String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
那么用户名输入 admin' OR '1'='1，密码随便输入什么，拼出来的SQL就变成了：
sql复制SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'xxx';
因为OR的优先级低于AND，所以这个条件等于“用户名是admin”或者“1=1且密码等于xxx”。如果表里有一个admin用户，这条查询就直接返回了admin的信息，登录就被绕过了。更狠的还有直接输入 ' OR 1=1 -- ，把后面的条件注释掉，那就不仅仅是绕过用户名了，而是把整张表的数据都可能带出来。
4.2 防注入的正确姿势
防SQL注入最根本的办法就是参数化查询（预编译）。不管是Java的PreparedStatement、Python的cursor.execute带参数，还是MyBatis的 #{}，道理都一样：把SQL结构和数据分开，数据库先解析SQL语句结构，再绑定参数。这样用户输入再特殊，也只是作为字符串值传入，无法改变SQL语义。
另外，Web框架自带的ORM通常已经做好了参数化处理，用ORM反而更安全。但问题是，有些人一遇到复杂查询就忍不住写原生SQL，手写原生SQL的时候安全意识又没跟上，就成了注入重灾区。我的建议是：如果非要写原生SQL，那就强制自己只用参数化写法，靠意志力记住是不靠谱的。
还要注意数据库账号权限。即使发生注入，如果应用连接数据库的账号只有SELECT权限，攻击者也无法通过注入来修改数据。最小权限原则在这里能起到很好的兜底作用。
4.3 说说CTF里的绕过手法，但别只会背payload
CTF比赛里SQL注入算是入门必考的题型。它的常见绕过思路包括：注释符绕过（--、#、/* */）、大小写绕过（SeLeCt）、内联注释、编码绕过（URL编码、十六进制）、等价函数替换（substr换mid）等等。
理解这些绕过手法不是为了去攻击别人，而是为了在防御的时候知道对手可能出什么牌。比如看到有人访问 /product.php?id=1'，就该意识到有人可能在试探注入点；看到请求里出现了 CONCAT、UPDATEXML、EXTRACTVALUE 这类函数，就要警惕是不是有人在利用报错注入获取数据库信息。
我在看一些安全文章和漏洞报告时发现，很多真实世界的SQL注入漏洞，利用手法并不比CTF里的复杂，经常是连最基本的参数化都没做。所以比起学各种花哨的payload，把参数化查询、最小权限、输入校验这几件基础事做好，就能防住绝大多数攻击。
5. 慢SQL优化实战记录
5.1 先定位再优化，别上来就加索引
慢SQL优化最忌讳的就是不看监控、不看日志，一上来就“我觉得加个索引就行”。我见过很多人在没有确认瓶颈的情况下，随手加了一堆索引，最后不仅没变快，反而拖慢了插入和更新速度，因为每个索引在写入的时候都要维护。
正确的做法是先定位慢SQL。MySQL开启慢查询日志：
ini复制slow_query_log = ON
long_query_time = 1
slow_query_log_file = /var/log/mysql/slow.log
然后分析日志，看哪些SQL频繁出现、哪些查询耗时长。拿到具体SQL之后，用EXPLAIN查看执行计划：
sql复制EXPLAIN SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 10;
看几个关键字段：type（访问类型，all是全表扫描，range/ref是走索引）、rows（预估扫描行数）、Extra（是否出现filesort、using temporary，这些都是性能杀手）。
一般规律是：全表扫描 + 扫描行数大 + 排序临时表，这三点只要占了两条，就基本可以确定是优化目标了。
5.2 索引为什么有效，以及失效场景
索引提高查询速度的原理，可以简单理解成一本字典的目录。没有目录的时候要一页一页翻（全表扫描），有目录就可以直接跳到对应的页码范围（B+树查找）。索引的底层数据结构一般是B+树，它能保证每次查找的IO次数很少（通常树的高度就是2~4层），这就是为什么几百万行的表走索引也能毫秒级返回。
索引失效的情况才是最需要记笔记的。常见的索引失效场景有：
- 对索引列使用了函数，比如
WHERE DATE(created_at) = '2024-01-01'，索引就失效了，应该改成范围查询created_at >= '2024-01-01' AND created_at < '2024-01-02' - 隐式类型转换，比如索引列是varchar类型，查询条件却传了数字，数据库会隐式转换导致索引失效
- LIKE 前导通配符，
LIKE '%abc'无法走索引，LIKE 'abc%'可以 - OR条件中有一个字段无索引，整个查询可能不走索引
我之前处理过一个慢查询，表里有个phone字段是varchar类型，建了索引，但查询条件是 WHERE phone = 13800138000（数字类型），导致全表扫描。改成 WHERE phone = '13800138000' 之后，执行时间从秒级降到了毫秒级。
5.3 并行SQL和分页优化
“并行sql优化”这个热搜词可能有两种理解，一种是数据库内部的并行执行，一种是业务侧把多个SQL并发执行。我觉得日常开发里更常见的是后者。
比如从一个大表里统计不同维度的数据，写了四五条SQL，每条都要扫全表。如果串行执行，总耗时就是所有SQL耗时的累加。这种情况下可以用并行方式同时发出去，总耗时接近最慢的那条SQL的耗时。不过要注意控制并发度，数据库连接数和CPU资源是有限的，并发太高反而会把数据库打满。
至于分页优化，经典的深分页问题：LIMIT 100000, 20 为什么慢？因为数据库要扫描出前100020条记录然后丢弃前10万条。优化方式是改成基于游标（上一页最后一条记录的ID）的分页：
sql复制SELECT * FROM orders WHERE id > 100000 ORDER BY id LIMIT 20;
原理很简单，数据库可以从索引里直接定位到id=100000的位置继续往后扫，避免了前10万条的无谓扫描。
5.4 真实优化案例：一张订单表的慢查询处理
最后分享一个我亲手优化过的案例。当时线上有个报表查询，要查某个时间段内所有用户的总订单金额，API超时经常超过10秒。原始SQL大致是：
sql复制SELECT user_id, SUM(amount) FROM orders WHERE created_at BETWEEN '2024-01-01' AND '2024-02-01' GROUP BY user_id;
EXPLAIN后发现全表扫描，orders表当时有2000万行左右。第一件事是看有没有可用索引，结果发现created_at上没建索引。加上复合索引 (created_at, user_id, amount) 之后，查询变成了覆盖索引扫描，耗时从8秒降到了0.3秒。
这里有个细节：我建的索引把查询需要的所有列都包含进去了，这样数据库直接扫描索引就能拿到结果，不需要回表查原数据，这种叫覆盖索引优化，效果立竿见影。如果只建 (created_at) 索引，虽然也能过滤时间段，但还需要回表取user_id和amount，性能会差一些。
6. 把SQL用在实际工作中
6.1 报表工具里的SQL取数
用Superset这类BI工具时，经常需要在图表设计阶段通过SQL计算来取数。Superset支持在虚拟数据集里写SQL，或者在图表设计的Metrics/Dimensions里用自定义SQL表达式。
我用Superset的经验是：能下推到数据库执行的聚合函数（比如SUM、COUNT）就直接在图表里配置，不要把所有数据拉到前端再聚合，那样浏览器和服务器都会遭殃。复杂的取数逻辑可以在“数据集 -> 编辑 -> 自定义SQL”里写一个视图级别的SQL，Superset会把它当虚拟表一样用。
但要注意，Superset生成的SQL很多时候和手写的不太一样，它会在外层包一层limit、group by之类的逻辑。如果最内层的SQL写得不严谨（比如SELECT列出了重复列名），外层包装后很可能报错。所以写虚拟数据集SQL时，每个字段名要唯一、要加别名，避免歧义。
6.2 把一个表的列更新为另一个表的列
热搜词里有一条“sql更新一个表中列为另外一个表中的列”，这需求挺常见的，比如用A表的手机号字段更新B表的联系人字段。
MySQL和SQL Server的写法不同。MySQL是UPDATE JOIN的语法：
sql复制UPDATE users u
JOIN customer_ids c ON u.id = c.user_id
SET u.phone = c.new_phone
WHERE c.new_phone IS NOT NULL;
SQL Server用的是UPDATE FROM：
sql复制UPDATE u
SET u.phone = c.new_phone
FROM users u
INNER JOIN customer_ids c ON u.id = c.user_id
WHERE c.new_phone IS NOT NULL;
这种更新操作有一个风险点：如果关联字段不是唯一的，可能导致一张表里的多行关联到另一张表的同一行，更新结果不可预测。我的习惯是执行之前先跑一遍SELECT，确认关联后每个目标的记录数符合预期再更新。
6.3 自然语言转SQL：工具能做到什么程度
最近“agent实现把自然语言转换成sql”这个话题很热。这些年自然语言转SQL（NL2SQL）技术进展确实很大，各大模型都能根据表结构生成比较像样的SQL。但我实际用下来的感觉是：处理简单单表查询问题不大，一到多表关联、复杂窗口函数、业务逻辑暗含的场景，生成的SQL经常有逻辑漏洞。
关键问题在于，模型对业务语义的理解终究是有限的。比如“上个月活跃用户里，订单金额超过平均值的”这种SQL，模型可能把“平均值”理解为全表平均值而不是分组平均值，逻辑就完全错了。
所以我个人的态度是：自然语言转SQL适合做报表初稿、辅助写查询，但上线前必须人工审查。更重要的是，你得自己懂SQL才能发现模型生成的SQL哪里有问题。这也是我坚持整理SQL笔记的原因——工具可以辅助，但底层的理解和判断力不能完全交给工具。
写到最后想说的
SQL这门语言看起来简单，翻来覆去就那么几个关键词，但真正用好的关键在于理解它的执行模型和数据特性。执行顺序决定了你能不能在头脑里“跑一遍”自己写的SQL，NULL和去重的细节决定了数据结果可不可信，索引和慢SQL优化决定了线上系统稳不稳，注入防范决定了你的系统安不安全。这几块内容整理下来，既是我过去经验的小结，也算是一份给新人的避坑手册。SQL这个东西没有太多捷径，踩坑、复盘、再踩坑、再复盘，慢慢就有手感了。希望这份笔记能帮你少走一些我走过的弯路。