企业官网建设流程全解析

1. 计算机体系结构到底在聊什么

1.1 从“装机单”到“体系结构”的认知跃迁

很多人第一次接触“计算机体系结构”这个词，是在课程表上，或者某本厚得能当枕头的教材封面上。我当年也一样，以为这门课就是讲CPU怎么插、内存怎么装、主板怎么选。真正学进去之后才发现，装机那点事叫“硬件组装”，而体系结构讨论的是另一层东西——一台机器为什么长成这样，它的设计者在权衡什么，哪些东西被刻意做成了这样而不是那样。

打个比方，如果把计算机比作一座城市，那么数字电路是砖瓦和钢筋，操作系统是市政管理，而体系结构就是这座城市的总体规划图：道路怎么修、水电网怎么铺、商业区和住宅区怎么划分。你不需要亲自去烧砖，但你必须理解为什么主干道要修八车道而不是四车道，为什么有些路口要建立交桥而不是红绿灯。这些决策直接决定了城市能容纳多少人、跑多快、堵不堵。

所以，计算机体系结构这门学问，核心就三件事：指令集怎么定、数据怎么流、性能怎么算。它站在软件和硬件的交界线上，往上看是编译器、操作系统、应用程序，往下看是逻辑门、晶体管、电路板。这个位置非常特殊，特殊到学懂它之后，你看任何一台计算设备的眼光都会变——你不再只看参数表上的数字，而是会去想这些数字背后的设计取舍。

1.2 为什么“概览索引”比死磕细节更重要

我见过太多人学体系结构的方式是：翻开第一章，看到“冯·诺依曼结构”五个字，然后开始逐字逐句啃，啃到流水线那一章就卡住了，再往后就放弃了。问题出在哪？出在没有先建立地图就开始赶路。

“概览索引”这四个字，其实点出了这门学问最有效的学习路径：先看全貌，再查细节。就像你去一个巨大的图书馆，进门第一件事不是随便抽一本书开始读，而是先看楼层索引——哪层放什么类别的书，你要找的东西大概在哪个区域。有了这个索引，你后面无论查什么资料，都能快速定位，而不是在书架间乱转。

计算机体系结构的知识体系非常庞大，从最顶层的“计算机分几类”到最底层的“cache行怎么替换”，中间跨越了十几个抽象层级。如果没有一个清晰的索引框架，你学到的知识就是一堆散落的珠子，串不起来。而一旦你有了索引，每学一个新知识点，你都知道它挂在哪根枝上，和哪些已有知识相连。这种“挂载感”是学习效率的关键。

我自己的做法是：拿一张A3纸，横过来，中间画一条线代表“软硬件接口”，上面写软件相关（指令集、编译优化、操作系统支持），下面写硬件相关（流水线、存储层次、并行结构），左右两边分别标注“性能”和“功耗”两个维度。每次学到新东西，就往这张图上添一笔。这张图就是我的“概览索引”，它不追求细节完整，但追求结构清晰。

1.3 这门学问适合谁，不适合谁

先说适合谁。如果你是计算机相关专业的学生，体系结构是必修课，没得选，但你可以选择学得明白还是学得糊涂。如果你是做后端开发、嵌入式开发、性能优化的工程师，体系结构知识直接决定你能不能写出“对硬件友好”的代码。我见过一个做数据库优化的朋友，他花了两周时间把体系结构里的存储层次和cache一致性协议搞清楚，然后回头改查询引擎的内存访问模式，性能直接提升了三成。这种案例在工程界并不少见。

如果你是对计算机底层好奇的爱好者，体系结构也能给你带来巨大的满足感——你会终于明白为什么内存要分DDR几代、为什么SSD比机械硬盘快那么多、为什么手机芯片要有大小核。这些日常接触到的技术名词，背后都是体系结构的设计决策。

那不适合谁呢？如果你只想学“怎么用电脑”而不是“电脑怎么工作”，那体系结构确实不是你的菜。如果你追求的是快速上手某个框架、某个工具，那体系结构这种偏底层、偏原理的学问，短期内确实给不了你直接的回报。但话说回来，越是往上走，底层的理解就越值钱。这个道理，工作几年之后体会会越来越深。

2. 核心知识框架的拆解与索引方法

2.1 指令集：软硬件之间的“合同”

指令集是体系结构里最核心的概念之一，但很多教材把它讲得太枯燥了。我的理解是：指令集就是软件和硬件之间签的一份合同。软件说“我要做加法”，硬件说“好，你用ADD这条指令，把两个数放在寄存器里，我帮你算”。合同一旦签定，双方都得遵守——软件不能随便发明新指令，硬件也不能随便改指令的行为。

这份合同有两种签法：一种是复杂指令集，一种是精简指令集。复杂指令集的思路是“硬件多干活，软件少干活”，一条指令可以完成很复杂的操作，比如从内存取数、做运算、再存回内存，一条指令全包了。精简指令集的思路反过来：“硬件只干最简单的活，复杂的操作由软件用多条简单指令组合完成”。

这两种思路的取舍，背后是硬件复杂度与软件复杂度之间的权衡。复杂指令集让编译器好写，但硬件设计复杂、功耗高；精简指令集让硬件简单高效，但编译器要做更多优化工作。早年间复杂指令集占主导，后来精简指令集在移动端大放异彩，现在两者又在互相借鉴。这个演变过程本身就是一部精彩的工程权衡史。

学习指令集的时候，我建议不要一上来就背指令格式。先搞清楚三件事：有哪些寄存器、支持哪些数据类型、寻址方式有几种。这三件事搞清楚了，再看具体指令就是查表的事。寄存器是CPU的“工作台”，数据类型决定了“能加工什么材料”，寻址方式决定了“材料怎么搬到工作台上”。这三个问题想明白了，指令集就不再是一堆枯燥的编码。

2.2 存储层次：为什么计算机要有“记忆分级”

存储层次是体系结构里最贴近实际性能的部分。很多人写代码时觉得“内存访问都差不多快”，但实际上，从寄存器到cache到主存到硬盘，访问速度差了好几个数量级。这个差距有多大？打个比方：如果寄存器访问是一次呼吸的时间（约1秒），那么cache访问就是走几步路的时间（几分钟），主存访问就是出趟远门的时间（几天），硬盘访问就是跨越地质年代的时间（几百万年）。

正因为差距如此悬殊，计算机才设计了“存储层次”这个东西。它的核心思想是：把最常用的数据放在最快但最小的存储里，把不常用的数据放在慢但大的存储里。这就像你办公桌上只放今天要用的文件，其他文件放文件柜，再久远的放仓库。每次需要什么，先从桌上找，找不到去文件柜，再找不到才去仓库。

这个“找”的过程就是cache的命中与缺失。命中就是桌上找到了，直接拿来用；缺失就是桌上没有，得去文件柜甚至仓库拿，拿的时候还要顺便把桌上一些不常用的文件挪走，腾出地方放新拿来的。这个“挪走”的策略就是替换算法，常见的有LRU、LFU等。

理解存储层次的关键，是理解局部性原理。时间局部性是说“刚用过的东西很可能马上再用”，空间局部性是说“刚用过的东西附近的东西很可能马上要用”。这两个原理是cache能起作用的理论基础。你写的代码如果局部性好，cache命中率就高，程序就跑得快；如果局部性差，cache频繁缺失，再好的CPU也救不了你。

2.3 流水线：让CPU“同时做多件事”的艺术

流水线的思想其实特别朴素：把一件大事拆成若干小步，每一步由专门的工位负责，东西在工位之间流动。就像工厂的装配线，一辆汽车从底盘开始，经过发动机安装、轮胎安装、喷漆、检测，每个工位同时都在干活，整体产出速度就上去了。

CPU的流水线也是这样。一条指令的执行可以拆成取指、译码、执行、访存、写回五个阶段，每个阶段由不同的硬件单元负责。理想情况下，每个时钟周期都有一条指令完成，虽然单条指令的延迟没变，但吞吐率提高了。

但流水线不是免费的午餐。它带来了一系列问题，最典型的就是冒险。结构冒险是“两个阶段抢同一个硬件”，数据冒险是“后一条指令需要前一条指令还没算完的数据”，控制冒险是“遇到分支不知道下一条该取哪”。解决这些问题需要转发、停顿、分支预测等技术，每一项都有复杂的权衡。

我学流水线的时候，最大的收获不是记住了那几种冒险的名字，而是理解了**“吞吐率”和“延迟”是两个不同的指标**。很多性能优化都是在牺牲延迟换吞吐，或者反过来。这个思维框架一旦建立，你看很多系统设计都会豁然开朗。

2.4 并行结构：从指令级到线程级

并行是体系结构里最“热闹”的领域，因为它是性能提升的主要途径。当单核频率提不上去的时候，大家就开始想办法“同时做更多事”。并行的层次有很多：指令级并行是在一条指令流里找可以同时执行的指令，线程级并行是同时执行多个线程，数据级并行是对一堆数据同时做同样的操作。

指令级并行主要靠超标量和超长指令字两种思路。超标量是说硬件自己判断哪些指令可以并行，超长指令字是说编译器把可以并行的指令打包好告诉硬件。前者硬件复杂但软件简单，后者硬件简单但软件复杂，又是一次经典的权衡。

线程级并行最典型的就是多核。多核的设计挑战在于缓存一致性——每个核都有自己的cache，怎么保证大家看到的内存数据是一致的？这需要一套协议来协调，常见的如MESI协议。这套协议的设计非常精妙，核心思想是：读的时候大家共享，写的时候独占。一个核要写某个数据，必须先让其他核把该数据的副本失效，然后自己独占修改。

数据级并行在图形处理和科学计算里特别常见，SIMD（单指令多数据）就是典型代表。一条指令同时对多个数据做同样的操作，比如同时算八个数的加法。这种并行方式效率极高，但要求数据之间没有依赖关系。

3. 性能分析的实操框架

3.1 用公式拆解性能：从“感觉慢”到“知道哪慢”

性能分析最怕的就是“感觉慢”。感觉是主观的，没法量化，没法优化。体系结构给了一套非常实用的量化框架，核心就是那个经典的性能公式：

程序执行时间 = 指令数 × CPI × 时钟周期

这个公式看起来简单，但威力巨大。它把性能拆成了三个可独立分析的因子：指令数取决于编译器和指令集，CPI（每条指令的平均时钟周期数）取决于流水线效率和cache命中率，时钟周期取决于电路设计和工艺。

当你发现程序跑得慢时，可以用这个公式逐项排查：是指令数太多（编译器没优化好，或者算法复杂度高）？是CPI太高（cache频繁缺失，或者流水线经常停顿）？还是时钟频率上不去（功耗限制，或者设计问题）？每一项都有对应的优化手段。

我实际用这个公式排查过一个图像处理程序的性能问题。一开始以为是算法复杂度太高，后来用性能计数器一测，发现指令数并不多，但CPI高得离谱。再一查，原来是图像数据的访问模式对cache极不友好，每次处理都触发大量cache缺失。把数据访问顺序调整了一下，让空间局部性变好，CPI直接降了一半。

3.2 性能计数器：硬件给你的“体检报告”

现代CPU里都内置了性能计数器，可以统计各种硬件事件：执行了多少条指令、发生了多少次cache缺失、分支预测错了多少次、流水线停顿了多少个周期。这些计数器就是硬件的“体检报告”，告诉你程序在硬件层面到底发生了什么。

用性能计数器有个技巧：不要一次看太多指标。新手容易犯的错是把所有计数器都打开，然后被一堆数字淹没。正确的做法是先看最顶层的指标——比如IPC（每周期指令数），如果IPC很低，再往下查是cache的问题还是分支的问题。一层一层往下钻，像查案一样。

Linux下常用的工具是perf，用法很简单：

# 统计程序运行时的硬件事件 perf stat ./your_program # 查看cache缺失的详细情况 perf stat -e cache-misses,cache-references ./your_program # 查看分支预测情况 perf stat -e branch-misses,branches ./your_program

这些命令输出的数字，配合前面说的性能公式，能帮你快速定位瓶颈。我个人的经验是：大部分程序的性能问题，最终都能归结到cache缺失或分支预测失败上。把这两个问题解决了，性能通常会有明显提升。

3.3 Amdahl定律：优化之前先算算账

Amdahl定律是体系结构里最“泼冷水”的定律，但也是最实用的。它说的是：如果你只优化了程序的一部分，整体性能提升的上限取决于这部分占多大比例。公式很简单：

加速比 = 1 / ((1 - 可优化比例) + 可优化比例 / 优化倍数)

举个例子：如果一个程序有40%的时间花在某个函数上，你把这个函数优化了10倍，整体加速比是多少？代入公式：1 / (0.6 + 0.4/10) = 1 / 0.64 ≈ 1.56倍。也就是说，你花了很大力气优化了10倍，整体只快了1.56倍。

这个定律的意义在于：优化之前先算账，别把时间花在收益低的地方。我见过太多人花几天时间优化一个只占5%时间的函数，优化了100倍，整体提升不到5%。而如果去优化那个占50%时间的部分，哪怕只优化2倍，整体也能提升33%。

所以我的实操建议是：先用性能分析工具找到热点，按时间占比排序，从最大的开始优化。优化完一个再测一次，看新的热点在哪里，迭代进行。这个过程比盲目优化高效得多。

4. 常见问题与排查技巧实录

4.1 为什么我的程序“看起来”很快但实际很慢

这个问题我遇到过很多次，典型场景是：程序在测试数据上跑得飞快，一上真实数据就慢如蜗牛。原因通常是测试数据的规模太小，没有触发真实的性能瓶颈。

比如一个矩阵乘法程序，在小矩阵上跑，数据全在cache里，速度当然快。但真实数据是大矩阵，数据量远超cache容量，每次计算都要从主存取数，速度就下来了。这就是cache容量这个参数在起作用。

排查这类问题，关键是用真实规模的数据做测试，或者至少用能触发cache缺失的数据规模。另外可以用性能计数器确认：如果cache缺失率很高，那问题就在存储层次上。解决办法通常是分块——把大矩阵切成小块，让每块能放进cache，算完一块再算下一块。这个技术叫“循环分块”，是高性能计算里的基本功。

4.2 多线程程序为什么没有变快反而变慢

多线程程序变慢，最常见的原因是锁竞争和伪共享。锁竞争好理解：多个线程抢同一把锁，抢不到的只能等着，线程越多等得越久。伪共享则比较隐蔽：两个线程分别修改两个不同的变量，但这两个变量恰好位于同一个cache行里。一个线程修改了变量A，导致整个cache行失效，另一个线程的变量B也跟着失效，不得不重新从内存加载。

伪共享的排查可以用性能计数器看cache一致性相关的指标。解决办法是填充——在变量之间插入无用的字节，让它们落在不同的cache行里。比如：

struct { int counter_a; char padding[60]; // 填充，让counter_a独占一个cache行 int counter_b; } shared_data;

这个技巧在高并发编程里非常实用，但很多新手不知道。我第一次遇到伪共享问题时，排查了整整两天，最后用性能计数器才定位到。从那以后，我在写多线程代码时都会特别注意变量的内存布局。

4.3 分支预测失败为什么影响这么大

分支预测失败的影响，很多人低估了。现代CPU的流水线有十几级甚至二十几级，一旦分支预测失败，整条流水线都要清空重来，浪费的周期数非常可观。如果分支预测失败率是10%，而每次失败浪费15个周期，那么平均每条分支指令就要多花1.5个周期，这个开销在分支密集的代码里非常致命。

减少分支预测失败的方法有几个：把最可能执行的分支放在前面，帮助预测器学习；用条件传送指令代替分支，消除分支本身；把数据组织成无分支的形式，比如用查表代替条件判断。

我优化过一个字符串处理函数，里面有个循环里套着条件判断，分支预测失败率很高。后来把条件判断改成了位运算和查表，分支预测失败率降到了接近零，性能提升了将近一倍。这个案例让我深刻体会到：在现代CPU上，减少分支往往比减少指令数更有效。

4.4 常见问题速查表

这张表是我自己排查性能问题时常用的速查表，基本上覆盖了大部分常见场景。实际使用时，先用perf stat看顶层指标，然后根据现象查表定位方向，再用更细粒度的计数器确认具体原因。

5. 学习路径与资源索引

5.1 从“概览”到“深入”的三阶段路径

学体系结构最忌讳的就是“一上来就啃最难的”。我建议分三个阶段走：

第一阶段：建立地图。目标是知道体系结构包含哪些大块，每块解决什么问题。这个阶段不需要深入细节，看一些综述性的材料就行。重点是理解指令集、存储层次、流水线、并行结构这四大块之间的关系。这个阶段大概花一到两周。

第二阶段：逐块深入。选一块你最感兴趣的，或者工作中最需要的，深入进去。比如你做后端开发，那就重点学存储层次和cache；你做嵌入式，那就重点学指令集和流水线。这个阶段要动手做实验，用性能计数器观察真实程序的行为。这个阶段大概花一到两个月。

第三阶段：融会贯通。当你对各个块都有了一定理解之后，回头再看整体，会发现很多之前没注意到的联系。比如指令集的设计如何影响流水线的实现，存储层次如何影响并行程序的性能。这个阶段没有终点，是持续终生的学习。

5.2 动手实验比看书更重要

体系结构是一门非常“实验性”的学问。光看书上的框图，你永远无法真正理解cache缺失的代价有多大、流水线停顿有多浪费。必须动手做实验，让数字说话。

最简单的实验方式是用perf工具分析你日常写的程序。比如写一个遍历二维数组的程序，分别按行遍历和按列遍历，用perf stat看两者的cache缺失率差异。你会直观地看到，同样逻辑的代码，仅仅因为访问顺序不同，性能可以差好几倍。这种“亲眼看到”的冲击，比看书上的文字描述强一百倍。

进阶一点的实验是写一些微基准测试，专门测试某个硬件特性。比如测试不同大小的数组的遍历速度，画出“数组大小-访问时间”的曲线，你会看到曲线在某个点突然上升——那个点就是cache容量的边界。这种实验能帮你建立对硬件参数的“手感”。

5.3 我个人的学习资源清单

说到资源，我不太想列一堆书名，因为每个人的基础和学习风格不同。我更想分享的是怎么找资源、怎么筛选资源的方法。

首先，教材选一本经典的就行，不用贪多。经典教材的好处是结构清晰、概念准确，适合建立框架。但教材的缺点是更新慢，最新的硬件特性可能没有覆盖。所以教材用来打基础，最新的知识要靠论文和技术文档。

其次，厂商的技术文档是第一手资料。CPU厂商会发布详细的优化手册，里面有很多实际案例和具体参数。这些文档虽然枯燥，但信息密度极高，是进阶的必经之路。

最后，性能分析工具的文档要常翻。perf、VTune这些工具的功能非常丰富，很多高级用法藏在文档深处。我每次遇到新的性能问题，都会去翻工具文档，经常能找到之前不知道的功能。

提示：学习体系结构时，不要追求“全部记住”。这门学问的知识量太大，记住所有细节既不可能也没必要。关键是建立索引框架，知道遇到问题时去哪里查、怎么查。索引比记忆重要得多。

6. 体系结构思维的实际应用

6.1 写代码时脑子里要有“硬件模型”

学了体系结构之后，我写代码的习惯发生了很大变化。以前只关心算法复杂度，现在会多想一层：这段代码在硬件上跑起来是什么样子的。

比如遍历一个二维数组，我会下意识地让内层循环访问连续的内存地址，因为这样空间局部性好，cache命中率高。比如写多线程代码，我会注意让不同线程访问的数据尽量分散在不同的cache行里，避免伪共享。比如写条件判断，我会尽量把最可能成立的条件放在前面，帮助分支预测器。

这些习惯看起来是小事，但累积起来对性能的影响非常大。而且这些优化不需要改变算法，只是调整代码的组织方式，成本很低，收益很高。

6.2 性能优化从“猜”变成“测”

以前做性能优化，很多时候靠猜：觉得这里慢就改这里，觉得那里慢就改那里。学了体系结构之后，我学会了用数据说话。先用性能计数器测出瓶颈在哪里，再针对性地优化，优化完再测一次确认效果。

这个“测量-优化-再测量”的循环，比盲目猜测高效得多。而且性能计数器给出的信息非常具体：是cache缺失、是分支预测失败、还是流水线停顿，一目了然。有了这些信息，优化方向就非常明确。

我印象最深的一次优化经历，是帮一个团队优化他们的数据处理管道。他们之前一直在优化算法，但效果不明显。我用性能计数器一测，发现瓶颈根本不在算法上，而在数据的内存布局上——他们的数据结构对cache极不友好，每次处理都触发大量缺失。调整了数据布局之后，性能直接翻倍。这个案例让我更加坚信：在硬件层面找瓶颈，往往比在算法层面找瓶颈更有效。

6.3 理解“为什么这样设计”比“记住怎么设计”更重要

体系结构里有很多设计决策，看起来很奇怪，但背后都有深刻的理由。比如为什么cache要分多级？为什么流水线要那么深？为什么要有乱序执行？这些问题如果只记结论，很快就会忘记。但如果理解了背后的权衡，就能举一反三。

举个例子：cache分多级，是因为速度、容量、成本三者不可兼得。一级cache要快，所以做得很小；二级cache可以慢一点，所以做大一些；三级cache更慢，但更大。这样分级之后，大部分访问在一级cache就命中了，少数访问才需要走到后面几级。这个设计思路和存储层次的整体思想是一致的：用层次结构来平衡速度、容量和成本。

理解了这一点，你再看其他系统设计，会发现很多类似的分层思想。比如CDN的分层缓存、数据库的多级索引、操作系统的多级页表，本质上都是同一个思路。这种“跨领域的模式识别”，是学体系结构最大的收获之一。

7. 一些踩过的坑和真心建议

7.1 不要一开始就陷入细节

我刚开始学体系结构时，最大的错误就是试图把每个细节都搞懂。看到流水线的冒险，就把所有冒险类型和解决方案都背下来；看到cache替换算法，就把LRU、LFU、随机替换的优缺点都记下来。结果就是：花了大量时间，但脑子里是一团乱麻，遇到实际问题还是不知道从哪下手。

后来我改变了策略：先建立框架，再填充细节。框架就是前面说的“概览索引”——知道有哪些大块，每块解决什么问题，块与块之间是什么关系。有了框架之后，细节知识就有了“挂载点”，学起来快得多，也不容易忘。

所以我的建议是：第一遍学的时候，允许自己“不求甚解”。看到不懂的细节，标记一下，继续往下走。等把整体框架建立起来之后，再回头深入那些细节。这时候你会发现，很多之前不懂的东西，现在自然就懂了。

7.2 性能优化要“先测量再动手”

这个坑我踩过不止一次。有一次优化一个程序，凭直觉觉得瓶颈在某个循环上，花了两天时间优化那个循环，结果整体性能几乎没变。后来用性能计数器一测，发现真正的瓶颈在另一个地方——一个我完全没注意到的内存分配操作。

从那以后，我给自己定了一条规矩：没有测量数据，不动手优化。哪怕直觉再强烈，也要先用工具确认。性能计数器、profiler、日志，什么工具都行，关键是要有数据支撑。

这条规矩帮我省了大量时间。因为很多时候，直觉是错的。程序的实际行为和我们的想象往往有差距，只有测量才能揭示真相。

7.3 多和同行交流，但要有自己的判断

体系结构这个领域，不同的人有不同的理解角度。做编译器的关注指令集和寄存器分配，做操作系统的关注存储层次和中断处理，做硬件的关注流水线和功耗。多和不同背景的人交流，能帮你看到自己忽略的维度。

但交流的同时，也要有自己的判断。我见过一些“经验之谈”，听起来很有道理，但实际上经不起推敲。比如有人说“cache越大越好”，但实际上cache大了之后，访问延迟也会增加，而且成本上升。又比如有人说“分支越少越好”，但实际上有些分支用条件传送代替后，反而增加了计算量。

所以我的态度是：听别人的经验，但用自己的实验验证。体系结构是一门实验科学，任何结论都应该能用数据支撑。没有数据支撑的“经验”，只能作为参考，不能作为依据。

7.4 保持对硬件的“好奇心”

最后说一点感受。学体系结构这些年，我最大的收获不是某个具体的知识点，而是对硬件保持好奇心。每次看到新的CPU发布，我会去看它的微架构有什么变化；每次看到新的存储技术，我会去想它对存储层次有什么影响；每次看到新的并行框架，我会去分析它在硬件层面是怎么实现的。

这种好奇心让学习变成了一件有趣的事，而不是负担。而且这种好奇心带来的知识积累，会在意想不到的时候发挥作用。比如有一次面试，面试官问了一个关于内存屏障的问题，我因为平时关注硬件内存模型，答得很顺畅。这种“意外收获”，是持续学习的最好回报。

体系结构这门学问，入门可能有点枯燥，但一旦进去，会发现里面是一个非常精彩的世界。它连接着软件和硬件，连接着理论和实践，连接着过去和未来。希望这篇索引能帮你找到入口，剩下的路，自己走起来会更有意思。