GCC四阶段编译原理与多文件工程构建实战-平芜编程栈

1. 为什么“单文件编译”根本不是入门，而是认知陷阱？

刚接触C语言时，我见过太多人卡在“hello world跑不起来”这一步——不是代码写错了，而是压根没搞清gcc在背后干了什么。他们把gcc hello.c -o hello当成一个原子操作，像按开关一样执行，却不知道这行命令背后藏着四个截然不同、彼此依赖又可独立控制的阶段：预处理、编译、汇编、链接。更麻烦的是，一旦项目从单个.c文件扩展到两个、五个、二十个源文件，甚至混入.h头文件、静态库.a、动态库.so，那个“一键编译”的幻觉就彻底崩塌了。你突然发现undefined reference to 'func'报错满天飞，而错误位置离你修改的代码隔着三四个文件；或者改了一行头文件，却要等三分钟重新编译整个工程；又或者在同事电脑上能跑的代码，在你机器上死活链接失败——所有这些，根源都不在语法，而在对gcc工作流的模糊理解。

这根本不是“会不会用gcc”的问题，而是“有没有建立编译器视角”的分水岭。所谓“编译器视角”，就是能清晰画出一张图：源码从文本字符开始，经过预处理器剔除注释、展开宏、插入头文件内容，变成纯净的翻译单元；再由编译器将C语义翻译成与平台无关的汇编指令；接着汇编器把汇编指令转为二进制目标码（.o文件），此时每个.o都是独立的、未解析外部符号的“零件”；最后链接器像装配工一样，把所有.o和库文件拼在一起，填平函数调用地址、变量引用地址这些“空洞”，生成最终可执行体。这个链条里，任何一环出问题，都会导致下游崩溃，而错误信息往往只指向最后一环（链接失败），让你在上游反复试错。

提示：gcc默认把这四步串成流水线自动执行，掩盖了中间产物。但真正的工程能力，始于你能主动拆开它——用-E看预处理结果，用-S停在汇编层，用-c只生成目标文件，用-v看完整命令行。这不是炫技，是调试的起点。

我带过的某高校嵌入式课程中，A同学坚持“只要能跑就行”，结果在做一个含12个模块的电机控制项目时，因头文件包含路径配置错误，导致某个关键结构体定义被重复展开两次，编译通过但运行时内存越界。排查花了整整两天，最后发现只是Makefile里少了一个-I./inc参数。而B同学从第一天起就习惯用gcc -E main.c | head -20检查宏展开是否符合预期，用nm module.o查看目标文件导出的符号表，遇到链接错误第一反应是ldd ./program查动态依赖。两人进度差距在第三周就拉开了——前者还在救火，后者已开始优化启动时间。

所以本篇不讲“怎么安装gcc”，也不列一堆参数手册。我们要做的是：亲手把gcc这条流水线拧开、看清每个齿轮的齿形、知道它卡住时该往哪滴油、以及当产线要扩能（多文件工程）时，如何重新设计传送带布局。接下来的内容，全部基于真实跨平台嵌入式项目（模拟项目X）的演进过程——从单文件裸机驱动，到含37个源文件、4类硬件抽象层、2个第三方静态库的完整固件工程。所有命令、配置、陷阱，都来自实测日志。

2. 四步拆解：预处理、编译、汇编、链接的底层逻辑与实操验证

2.1 预处理阶段：宏、头文件与条件编译的真实战场

预处理（Preprocessing）是gcc流水线的第一道闸门，由cpp（C Preprocessor）执行。它的任务看似简单：处理#include、#define、#ifdef等指令，输出一个“纯C代码”文件。但正是这个“纯”字，埋下了最多隐蔽坑。我们用一个极简例子直击本质：

// config.h #define VERSION "1.2.0" #define DEBUG_MODE 1 // main.c #include "config.h" #include <stdio.h> int main() { #ifdef DEBUG_MODE printf("Debug build, version %s\n", VERSION); #else printf("Release build\n"); #endif return 0; }

执行gcc -E main.c > main.i后，main.i文件开头几行是这样的（删减版）：

# 1 "main.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 1 "<command-line>" 2 # 1 "main.c" 2 # 1 "config.h" 1 # 1 "main.c" 2 # 1 "/usr/include/stdio.h" 1 3 4 // ... 大量系统头文件内容 # 1 "main.c" 2 int main() { printf("Debug build, version %s\n", "1.2.0"); return 0; }

注意两点：第一，#include "config.h"被完全替换成其内容，且VERSION宏已被字符串字面量"1.2.0"直接替换；第二，#ifdef DEBUG_MODE分支被预处理器彻底删除，只留下printf那一行——这意味着DEBUG_MODE的值在编译阶段已固化，后续任何修改都不会影响已生成的目标文件。

注意：预处理不检查语法！你可以写#define X int y = ;，gcc -E照样通过，但下一步编译必然报错。这是新手常踩的坑：以为预处理报错=代码错，其实可能只是头文件路径不对或宏定义有歧义。

实战中更危险的是头文件包含顺序。假设driver.h依赖hal.h中的类型定义，但你在main.c里先#include "driver.h"再#include "hal.h"，预处理器会原样展开driver.h，而其中引用的类型在hal.h出现前未声明，编译直接失败。解决方案不是硬记顺序，而是用-H参数让gcc打印包含树：

gcc -H -c main.c 2>&1 | head -15

输出类似：

. ./driver.h . ./hal.h .. /usr/include/stdio.h

清晰显示driver.h内部确实包含了hal.h，说明问题出在driver.h自身未做防护。此时应在driver.h开头加卫士：

#ifndef DRIVER_H #define DRIVER_H #include "hal.h" // 显式声明依赖 // ... driver代码 #endif

2.2 编译阶段：从C代码到汇编指令的语义翻译

编译（Compilation）是真正理解C语言语义的阶段。它读取预处理后的.i文件，进行词法分析、语法分析、语义分析、中间代码生成、优化，最终输出汇编代码（.s文件）。这一步的关键在于：它只关心单个翻译单元（translation unit），即一个.i文件，完全不涉及其他文件中的函数或变量。

继续用main.c为例，执行：

gcc -S -O2 main.c -o main.s

生成的main.s（x86-64 Linux）核心片段：

main: .LFB0: .cfi_startproc subq $8, %rsp .cfi_def_cfa_offset 16 leaq .L.str(%rip), %rdi movl $0, %eax call printf@PLT movl $0, %eax addq $8, %rsp .cfi_def_cfa_offset 8 ret .L.str: .asciz "Debug build, version %s\n"

看到call printf@PLT了吗？这里printf只是一个符号名，编译器并不知道它在哪定义，也不去查——那是链接器的工作。编译器只确保：调用约定正确（参数放%rdi）、返回值处理得当、栈平衡。如果main.c里写了extern int unknown_func();，编译器同样会生成call unknown_func@PLT，只要语法合法就放行。

这就是多文件工程的基石：每个.c文件独立编译成.o，互不干扰。你改utils.c，只需重编utils.o，main.o完全不用碰。但这也带来约束：所有跨文件引用必须通过头文件声明，且声明与定义必须严格一致。比如utils.h声明：

void log_message(const char* msg, int level);

而utils.c定义成：

void log_message(char* msg, int level) { ... } // 错！const缺失

编译单个文件都没问题，但链接时main.o调用log_message传入const char*，而utils.o期望char*，类型不匹配导致运行时未定义行为（UB）。gcc 11+ 默认开启-Wcast-qual警告，但很多旧项目仍忽略。

2.3 汇编阶段：二进制目标文件的结构解密

汇编（Assembly）是机械的转换：把人类可读的汇编指令（.s）翻译成CPU可执行的机器码（.o文件）。.o文件不是可执行体，而是ELF（Executable and Linkable Format）格式的“目标文件”，包含代码段（.text）、数据段（.data）、未初始化数据段（.bss）、符号表（.symtab）、重定位表（.rela.text）等。

用objdump查看main.o：

objdump -t main.o | grep -E "(main|printf)"

输出：

0000000000000000 l df *ABS* 0000000000000000 main.c 0000000000000000 g F .text 000000000000001a main 0000000000000000 *UND* 0000000000000000 printf

解读：main是全局函数（g），位于.text段，大小0x1a字节；printf是未定义符号（*UND*），地址为0——这正是链接器要填的“空洞”。

再看重定位表：

objdump -r main.o

输出关键行：

RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 000000000000000f R_X86_64_PLT32 printf-0x4

意思是：在.text段偏移0xf处（即call指令的位置），需要填入printf的PLT（Procedure Linkage Table）入口地址，当前占位值是printf-0x4（链接器计算时会修正）。

提示：.o文件里的符号分三类——定义（如main）、引用（如printf）、局部（如static int counter;）。链接器只解析全局符号，static函数不会出现在.symtab中，这是实现模块封装的底层机制。

2.4 链接阶段：符号解析与地址重定位的终极博弈

链接（Linking）是gcc流水线的终点，也是多文件工程成败的判决点。它接收所有.o文件和库（.a/.so），完成两件大事：符号解析（Symbol Resolution）和重定位（Relocation）。

符号解析：为每个*UND*符号找到唯一定义。规则很残酷——全局符号在多个.o中定义？报错multiple definition；全局符号未定义？报错undefined reference。但static符号不受此限，因为它们只在本.o内有效。

重定位：把每个.o中“相对地址”（如call printf@PLT中的偏移量）替换成最终绝对地址。例如main.o中printf调用点偏移0xf，链接器查libc.so得到printf真实地址0x7ffff7a2b000，就往0xf处写入该值。

我们用一个经典多文件案例演示：

// calc.h int add(int a, int b); int mul(int a, int b); // calc.c #include "calc.h" int add(int a, int b) { return a + b; } int mul(int a, int b) { return a * b; } // main.c #include "calc.h" #include <stdio.h> int main() { printf("%d\n", add(2, 3)); return 0; }

编译：

gcc -c calc.c -o calc.o gcc -c main.c -o main.o

此时calc.o有add和mul定义，main.o引用add。链接：

gcc main.o calc.o -o program

成功。但如果误写成：

gcc calc.o main.o -o program # 顺序颠倒！

在某些老版本gcc下可能失败，因为链接器从左到右扫描，calc.o里没有未定义符号，main.o的add引用在calc.o之后才出现。现代gcc已优化，但理解此机制对调试大型Makefile至关重要。

更隐蔽的是库链接顺序。假设你用libmath.a（静态库）和libc.so（动态库），必须gcc main.o -lmath -lc，不能-lc -lmath——因为链接器对-l是单向扫描：-lmath解决main.o的数学函数引用，-lc解决libmath.a内部可能调用的printf等。顺序反了，libmath.a的引用就悬空。

3. 多文件工程的构建逻辑：从手动链接到Makefile自动化

3.1 手动构建的必然崩溃：为什么你不能靠记忆管理37个文件

当项目只有2个文件时，手动编译尚可：

gcc -c main.c -o main.o gcc -c calc.c -o calc.o gcc main.o calc.o -o program

但到5个文件（main.c,calc.c,io.c,timer.c,debug.c），命令行就变成：

gcc -c main.c -o main.o && \ gcc -c calc.c -o calc.o && \ gcc -c io.c -o io.o && \ gcc -c timer.c -o timer.o && \ gcc -c debug.c -o debug.o && \ gcc main.o calc.o io.o timer.o debug.o -o program

这已显笨拙。而模拟项目X有37个源文件，分布在src/core/,src/hal/stm32/,src/drivers/,src/utils/四个目录，还依赖libcrypto.a和libusb.a两个第三方静态库。手动维护不仅效率低下，更致命的是无法保证增量编译——每次改一个.c，你得记住哪些.o需要重编，哪些可以复用。漏掉一个，程序就带着旧逻辑运行，bug难以复现。

更糟的是配置管理。嵌入式项目需指定：

目标架构：-mcpu=cortex-m4 -mfloat-abi=hard
浮点单元：-mfpu=fpv4-d16
内存布局：链接脚本stm32f407.ld
优化等级：调试用-O0 -g，发布用-O2 -DNDEBUG
宏定义：-DSTM32F407xx -DUSE_HAL_DRIVER

把这些全塞进一行gcc命令？可读性归零，修改成本爆炸。某次我接手一个遗留项目，其构建脚本是一行长达238个字符的gcc命令，含17个-I路径、9个-D宏、5个-L库路径。改一个路径，得数空格确认引号闭合——这种反人类设计，是工程化失败的典型症状。

3.2 Makefile的本质：声明式依赖图谱与自动化决策引擎

Makefile不是脚本，而是声明式依赖描述。它不告诉你“怎么做”，而是定义“什么依赖什么”以及“如何更新”。核心三要素：

目标（Target）：要生成的文件，如program
依赖（Prerequisites）：生成目标所需的文件，如main.o calc.o
命令（Commands）：生成目标的具体操作，如gcc main.o calc.o -o program

最简Makefile：

program: main.o calc.o gcc main.o calc.o -o program main.o: main.c calc.h gcc -c main.c -o main.o calc.o: calc.c calc.h gcc -c calc.c -o calc.o

执行make时，make工具：

读取Makefile，构建依赖图：program←main.o,calc.o；main.o←main.c,calc.h
检查时间戳：若main.c比main.o新，则执行gcc -c main.c -o main.o
若所有依赖都最新，则执行gcc main.o calc.o -o program

这才是真正的自动化——你只改代码，make自动推导该重编哪些.o，该重链哪个program。

但手写37个规则？显然不现实。Makefile的精髓在于模式规则（Pattern Rules）和自动变量（Automatic Variables）：

# 编译所有.c为.o的通用规则 %.o: %.c gcc $(CFLAGS) -I./inc -c $< -o $@ # 链接所有.o为program program: $(OBJ) gcc $(LDFLAGS) $^ -o $@ # 自动收集src/下所有.c文件 SRC := $(wildcard src/*.c) OBJ := $(SRC:.c=.o) # 全局编译选项 CFLAGS := -Wall -Wextra -O2 -g LDFLAGS := -L./lib -lcrypto -lusb

这里$<代表第一个依赖（main.c），$^代表所有依赖（main.o calc.o ...），$@代表目标（program）。$(SRC:.c=.o)是字符串替换函数，把src/main.c变成src/main.o。这套机制让Makefile从37行缩减到15行，且新增文件只需放src/目录，无需改Makefile。

3.3 实战避坑：Makefile中90%的错误源于这3个盲区

盲区1：隐式规则与覆盖冲突

Make内置大量隐式规则，如%.o: %.c默认用cc -c。如果你写：

main.o: main.c gcc -c main.c -o main.o

这没问题。但若写成：

main.o: main.c gcc -c main.c -o main.o main.o: utils.h # 错！重复目标

make会报错multiple target patterns。正确做法是把utils.h作为依赖加在第一行：

main.o: main.c utils.h gcc -c main.c -o main.o

盲区2：变量展开时机陷阱

CFLAGS = -O2 CFLAGS += -g # 这里+=是追加，等价于 CFLAGS := $(CFLAGS) -g # 但下面这行会出错！ CFLAGS = $(CFLAGS) -Wall # 递归展开，无限循环

正确写法：

CFLAGS := $(CFLAGS) -Wall # := 是立即展开赋值

盲区3：路径分隔符与空格灾难

Linux/macOS用/，Windows用\，但Makefile中路径必须用/。更危险的是文件名含空格：

SRC := src/main.c src/my app.c # 错！make把'my app.c'当两个文件

应改为：

SRC := src/main.c "src/my app.c" # 加引号

但最佳实践是禁止空格——这是工程规范，不是技术限制。

我在某物联网网关项目中，因Makefile里一个-I./inc写成-I ./inc（多了空格），导致所有头文件找不到，编译报几百个错误。排查2小时才发现是空格惹的祸——gcc把-I当选项，./inc当源文件，自然找不到。

4. 工程级实战：模拟项目X的完整构建体系与故障诊断链路

4.1 项目结构设计：分层架构与编译单元隔离

模拟项目X是一个STM32F407平台的工业数据采集固件，采用严格分层：

project/ ├── Makefile # 顶层构建入口 ├── config.mk # 配置开关（DEBUG/RELEASE, HAL/LL） ├── stm32f407.ld # 链接脚本，定义ROM/RAM布局 ├── inc/ # 公共头文件 │ ├── core/ # 核心层接口 │ ├── hal/ # 硬件抽象层接口 │ └── drivers/ # 驱动层接口 ├── src/ │ ├── core/ # 核心逻辑（37个.c中12个在此） │ ├── hal/ │ │ └── stm32/ # STM32 HAL实现（15个.c） │ └── drivers/ # 外设驱动（10个.c） ├── lib/ │ ├── libcrypto.a # OpenSSL精简版 │ └── libusb.a # USB协议栈 └── build/ # 构建产物（.o, .elf, .bin）

关键设计原则：

头文件卫士强制：所有.h以#ifndef XXX_H开头，#define XXX_H，#endif
依赖单向流动：core/可包含hal/和drivers/头文件，但反之不行
编译单元最小化：每个.c只包含必需的头文件，避免“全包含”（#include "all.h"）

这样设计使make能精准识别变更影响范围。改src/core/sensor.c，只重编sensor.o和program；改inc/hal/gpio.h，则所有包含它的.c（如src/hal/stm32/gpio.c,src/drivers/adc.c）都要重编。

4.2 构建流程详解：从源码到烧录镜像的七步链

模拟项目X的完整构建链（make all触发）：

预处理验证：gcc -E -Iinc src/core/main.c | grep -q "STM32F407xx"确保宏定义生效
编译所有源文件：并行执行gcc -c -Iinc -D... src/core/*.c -o build/core/%.o
链接可执行体：arm-none-eabi-gcc build/core/*.o build/hal/*.o -Tstm32f407.ld -o build/firmware.elf
生成二进制镜像：arm-none-eabi-objcopy -O binary build/firmware.elf build/firmware.bin
生成符号表：arm-none-eabi-nm -n build/firmware.elf > build/symbols.map
校验大小：arm-none-eabi-size build/firmware.elf | awk '{if($1>256*1024) print "ERROR: ROM overflow"}'
烧录准备：cp build/firmware.bin /media/usb/（挂载USB DFU设备）

每一步都可单独执行调试。例如第6步ROM溢出检查，是嵌入式开发的生命线——STM32F407 Flash仅512KB，超了就无法烧录。我们曾因一个未关闭的调试日志宏，导致代码膨胀12KB，size检查立刻报警。

4.3 故障诊断全景图：从报错信息逆向定位根因

当make失败时，绝不能只看最后一行红字。以下是真实排错链路（以某次undefined reference to 'HAL_GPIO_TogglePin'为例）：

Step 1：确认符号存在性
执行nm lib/libstm32_hal.a | grep TogglePin，输出为空 → 说明HAL库未编译此函数，或版本不匹配。

Step 2：检查头文件包含
grep -r "HAL_GPIO_TogglePin" inc/发现inc/hal/gpio.h有声明，但src/hal/stm32/gpio.c中无定义 → 定位到gpio.c缺失实现。

Step 3：验证编译选项
make V=1（显示详细命令）发现gcc命令中无-DHAL_GPIO_MODULE_ENABLED→ 查config.mk，发现该宏被注释 → 解除注释。

Step 4：清理重建
make clean && make，但依然失败 → 原因：gpio.o已存在且未更新。执行rm build/hal/stm32/gpio.o强制重编。

Step 5：终极验证
arm-none-eabi-readelf -s build/hal/stm32/gpio.o | grep TogglePin输出：

25: 00000000 0 FUNC GLOBAL DEFAULT 1 HAL_GPIO_TogglePin

→ 符号已定义，链接成功。

注意：make clean不能只删.o，还要删build/下所有产物。我们定义clean目标为：
clean: rm -rf build/*

4.4 性能优化实践：缩短37个文件的全量编译时间

37个文件全量编译耗时约42秒（i7-10875H）。优化手段：

并行编译：make -j8利用8核，降至11秒
预编译头文件（PCH）：将inc/core/common.h（含stdio.h,stdint.h,stm32f4xx.h）预编译：
```
gcc -x c-header -Iinc inc/core/common.h -o inc/core/common.h.gch
```
所有包含common.h的.c自动使用.gch，节省头文件解析时间，全量编译降至7.2秒
ccache加速：安装ccache，首次编译后缓存.o，后续相同输入直接命中缓存，平均编译时间<1秒

但PCH有代价：common.h一改，所有依赖它的.c必须重编。因此我们只对稳定的基础头文件启用PCH，业务头文件保持原生。

5. 跨平台构建的终极方案：CMake为何成为行业标准

5.1 Makefile的天花板：当项目需要支持Windows/Linux/macOS时

模拟项目X后期需支持PC端仿真（Linux）和Windows调试客户端。若坚持Makefile，就得维护三套：

Makefile.linux：用gcc
Makefile.windows：用mingw-w64-gcc
Makefile.macos：用clang

每套都要同步37个源文件列表、23个头文件路径、15个编译选项。一次添加新驱动，就要改三处——错误率飙升。

CMake的破局点在于抽象构建逻辑，生成平台专用构建文件。你只写一份CMakeLists.txt：

cmake_minimum_required(VERSION 3.10) project(SensorFirmware) # 设置C标准 set(CMAKE_C_STANDARD 11) # 添加可执行目标 add_executable(firmware src/core/main.c src/core/sensor.c # ... 其他35个文件 ) # 包含目录 target_include_directories(firmware PRIVATE inc) # 链接库 target_link_libraries(firmware crypto usb) # 条件编译 if(WIN32) target_compile_definitions(firmware PRIVATE WIN32_BUILD) elseif(UNIX AND NOT APPLE) target_compile_definitions(firmware PRIVATE LINUX_BUILD) endif()

然后：

Linux：mkdir build && cd build && cmake .. && make
Windows：mkdir build && cd build && cmake -G "MinGW Makefiles" .. && mingw32-make
macOS：mkdir build && cd build && cmake -G "Xcode" .. && open SensorFirmware.xcodeproj

CMake自动生成对应平台的构建文件（Makefile、MinGW Makefile、Xcode项目），你无需关心gcc还是cl.exe，-I还是/I。

5.2 CMake核心机制：目标（Target）驱动的依赖管理

CMake的核心是目标（Target）—— 可执行体、静态库、动态库。所有操作围绕目标展开：

add_executable(name src1.c src2.c)创建可执行目标
add_library(name STATIC src1.c)创建静态库目标
target_include_directories(name PRIVATE inc)为该目标设置头文件路径
target_link_libraries(app PRIVATE libname)声明链接依赖

关键优势：传递性（Transitivity）。若libhal设置了target_include_directories(libhal PRIVATE inc/hal)，则任何链接libhal的目标（如firmware）自动获得inc/hal路径，无需重复声明。

这解决了Makefile中“头文件路径散落各处”的顽疾。在模拟项目X中，我们将HAL层封装为add_library(hal STATIC src/hal/stm32/*.c)，驱动层为add_library(drivers STATIC src/drivers/*.c)，主程序只需：

add_executable(firmware src/core/main.c) target_link_libraries(firmware PRIVATE hal drivers crypto)

CMake自动推导出所有依赖的头文件路径和链接顺序。

5.3 从零迁移：三天内将37文件Makefile升级到CMake

迁移不是重写，而是分步重构：

Day 1：基础骨架
创建CMakeLists.txt，用aux_source_directory()自动收集src/下所有.c，生成最简可执行体。验证cmake && make能跑通。
Day 2：分层建模
将src/按目录拆分为add_library(core ...),add_library(hal ...)等，用target_link_libraries连接。此时编译通过，但头文件路径需手动加target_include_directories。
Day 3：精细化治理
移除aux_source_directory，显式列出所有37个文件（IDE友好）；为每个库设置PRIVATE/INTERFACE/PUBLIC作用域；添加find_package(Threads REQUIRED)等外部依赖；集成cpack生成安装包。

迁移后收益：

新增文件只需在add_library中加一行，无需改Makefile逻辑
cmake --build . --target firmware统一构建命令，跨平台一致
IDE（CLion, VSCode）原生支持CMake，智能补全、跳转、重构开箱即用

我在某医疗设备公司主导此迁移，37个文件的工程，三人团队三天完成，后续两年新增21个模块，CMake配置零修改——因为新增模块只需在对应add_library中加源文件。

6. 终极建议：建立你的编译器心智模型与日常检查清单

写完这篇，我翻出自己2018年调试一个USB CDC驱动的笔记，当时为查undefined reference to 'USBD_CDC_Init'，在libusb.a里grep了3小时，最后发现是链接顺序错了——-lusb -lstm32应为-lstm32 -lusb。那晚凌晨三点，我删掉所有.o，重跑make V=1，看着命令行里正确的顺序闪过，长舒一口气。这种痛，每个C/C++开发者都经历过。

所以最后不谈高深理论，只给你一份我每天开工必做的gcc构建检查清单，贴在显示器边框上：