企业官网建设流程全解析

1. 这不是教科书，而是一份内核开发者的“心法手札”

你点开这个标题，大概率不是为了查某个函数的参数定义，也不是为了解决编译报错——而是想搞懂：为什么 Linux 内核看起来“乱糟糟”，却能稳稳跑在从树莓派到超算集群的每一台设备上？为什么别人改一行驱动就蓝屏，而资深维护者加个新调度策略还能顺带优化掉三年前的性能毛刺？这些背后没有魔法，只有一套被千万行代码反复锤炼、被全球开发者用血泪验证过的心智模型与设计哲学。它不写在任何官方文档首页，却藏在每一个#define宏里、每一段if (unlikely(...))判断中、每一次__rcu注释的沉默里。我做内核模块开发和定制裁剪十多年，带过三届内核方向的实习工程师，最常听到的困惑不是“怎么写”，而是“为什么要这么写”。这篇专栏第一讲，我们就抛开源码行号、跳过编译流程，直接拆解这套隐性操作系统——它不是知识，是判断力；不是语法，是直觉；不是API列表，而是当你面对一个全新硬件平台、一个模糊需求、一个深夜崩溃日志时，脑子里最先弹出的那几个关键问题。

它适合谁？如果你正在读《Linux内核设计与实现》，但合上书后仍觉得“懂了，但不会用”；如果你已经能写字符设备驱动，却总在并发场景下反复踩内存泄漏或竞态死锁的坑；如果你参与过国产芯片平台适配，发现上游补丁合入节奏慢得让人焦虑，却说不清根本卡点在哪——那你就是这篇内容最该盯住的人。它不教你make menuconfig怎么勾选，但会告诉你为什么CONFIG_PREEMPT_RT不能和CONFIG_SMP简单叠加；它不列struct task_struct的全部字段，但会让你一眼看出哪个字段的修改会牵动整个 CFS 调度器的时间复杂度。这不是入门指南，而是帮你把零散知识点焊成思维骨架的焊接剂。接下来所有内容，都基于一个铁律：内核不是被“写出来”的，而是被“约束出来”的——被硬件限制约束，被实时性约束，被可维护性约束，被向后兼容性约束。我们先从最反直觉的一点开始：为什么 Linux 内核要故意“拒绝”某些看似优雅的设计？

2. 核心设计哲学拆解：四条铁律如何塑造内核的“肌肉记忆”

2.1 铁律一：简单性优先于理论完备性（Simplicity over Perfection）

很多人第一次看mm/memory.c会被里面大量#ifdef CONFIG_ARM64和#ifdef CONFIG_X86_64的条件编译吓住，觉得“这代码太脏了”。但这就是内核对“简单性”的极致践行。举个真实案例：某次为某国产RISC-V平台移植内存管理子系统，团队最初想抽象出一个统一的arch_page_table_ops接口，把页表操作全封装成函数指针。方案很“面向对象”，UML图画得漂亮。但实测下来，每次页表遍历都要多一次间接跳转，TLB miss 率上升12%，在高吞吐网络场景下延迟抖动直接超标。最后回归到原始方案：为 RISC-V 单独写一套pgtable-riscv.h，用宏和内联汇编硬编码关键路径。性能恢复，代码行数反而少了300行。

提示：内核里90%的“丑陋”宏定义（比如__user、__iomem），本质都是编译期断言——它不解决运行时问题，但确保你在写错地址空间类型时，编译直接报错，而不是留个悬而未决的指针越界漏洞。

这种取舍的底层逻辑是：硬件差异是客观存在的物理事实，强行抹平只会制造更隐蔽的性能陷阱和调试地狱。内核选择把“差异”显式暴露在头文件里，让每个架构维护者对自己平台的边界有绝对掌控。你看到的“重复代码”，其实是不同硬件团队用自己最熟悉的方式，在各自物理约束下达成的最优解。所谓“简单”，不是代码行数少，而是因果链最短、副作用最少、可验证性最强。

2.2 铁律二：可预测性压倒一切（Predictability above All）

内核不是应用软件，它没有“等一等再响应”的奢侈。一个中断延迟超过100微秒，可能就导致USB设备失联；一次调度延迟抖动超过5毫秒，工业控制信号就会错相位。因此，内核所有核心子系统都围绕“可预测性”构建。以kthread（内核线程）为例：它的创建函数kthread_run()返回的是struct task_struct*，而非常见的int错误码。为什么？因为内核线程一旦启动，就必须保证其执行上下文绝对稳定——它不能像用户进程那样被SIGSTOP暂停，也不能被OOM killer杀掉。返回指针意味着：调用成功即代表资源已锁定、栈已分配、调度器已注册，后续任何操作都不再有“失败分支”需要处理。这种设计把错误处理前置到创建阶段，彻底消灭了运行时的不确定性分支。

再看spinlock_t：它在单CPU上被编译为空操作（do { } while(0)），而在SMP系统上才展开为真正的原子指令。表面看是“偷懒”，实则是精准控制：单核场景下加锁纯属冗余开销，强制加锁反而引入不必要的内存屏障和指令流水线冲刷。内核用编译期条件判断，把“可预测性”刻进每一行汇编。你写的驱动里如果对spin_lock(&dev->lock)做了空指针检查，那说明你还没理解这条铁律——锁变量本身必须是静态分配且永不为NULL，否则整个同步原语的可预测性基础就崩塌了。

2.3 铁律三：渐进式演化优于革命性重构（Evolution over Revolution）

Linus Torvalds 在邮件列表里最常说的话是：“Don’t break userspace.”（别破坏用户空间）。这句话背后是内核最顽固的基因：所有变更必须向前兼容，且兼容性承诺期限长达十年以上。2012年引入的cgroup v2并没有删除cgroup v1，而是让两者并存多年，直到容器生态全面迁移后才标记为废弃。这种“背着旧包袱走路”的设计，常被喷为“臃肿”，但它保障了企业级系统的升级确定性——银行核心交易系统不可能因为内核升级就重写整套监控脚本。

实操中这意味着什么？举个例子：当你为新硬件添加sysfs属性时，绝不能直接删掉老属性名。正确做法是：保留旧接口，内部逻辑指向新实现，并在文档里明确标注DEPRECATED；同时新增带版本号的新属性（如power_state_v2）。这样运维脚本可以平滑过渡，而新工具则默认使用新接口。内核的ioctl接口更是此哲学的集大成者：同一个ioctl号，通过传递不同结构体，可支持同一设备驱动的多代协议演进。你看不到“v1/v2”字样，但每个struct末尾的__u8 reserved[128]字段，就是留给未来扩展的缓冲区——它不解决当前问题，但为十年后的兼容性埋下伏笔。

2.4 铁律四：数据流驱动而非控制流驱动（Data-Flow First）

这是最容易被误解的一条。新手常以为内核是“事件驱动”的（中断来了就处理），但实际是数据流驱动：所有子系统都围绕“数据如何安全、高效、可追溯地流动”来组织。以网络栈为例：sk_buff（socket buffer）结构体不是简单的数据包容器，它的每个字段都在回答一个数据流问题——skb->dev指明入口网卡，skb->protocol标识L3协议，skb->ip_summed记录校验和状态，甚至skb->cb[]（control buffer）这个20字节的私有区域，也被各层协议用来暂存中间状态（TCP层存序列号，XDP层存重定向端口）。整个网络栈的函数调用链（netif_receive_skb→ip_rcv→tcp_v4_rcv）不是靠“if-else”串联，而是靠skb携带的元数据自动路由。

这种设计带来的直接好处是：你可以安全地插入新处理节点，而无需修改上游或下游代码。XDP（eXpress Data Path）技术之所以能绕过传统协议栈，正是因为它复用了sk_buff的数据结构约定——XDP程序拿到的xdp_buff与sk_buff共享内存布局，只是跳过了部分元数据初始化。当你在驱动里调用napi_schedule()时，你不是在“触发一个函数”，而是在向NAPI（New API）数据流引擎提交一个待处理的数据批次。理解这点，你就明白为什么内核开发者常说：“别想着‘调用’内核，要想着‘注入’数据流。”

3. 心智模型构建：从“代码阅读者”到“系统协作者”的三阶跃迁

3.1 第一阶：识别内核的“语言惯性”（Language Idioms）

内核代码有自己的一套“方言”，读懂它比读懂C标准更重要。比如container_of(ptr, type, member)宏：它不是简单的地址计算，而是内核对“类型安全”的妥协方案。C语言没有泛型，但内核需要从链表节点反推宿主结构体地址。container_of用offsetof和指针运算实现，但它的真正价值在于强制开发者声明类型关系——你必须明确写出struct my_dev *dev = container_of(list, struct my_dev, list_node);，这个过程本身就在训练你思考“这个链表节点属于哪个更大结构体”。我带过的实习生里，凡是能熟练手写container_of的，三个月内基本都能独立完成PCIe设备驱动框架搭建。

另一个典型是likely()/unlikely()分支提示。新手常把它当“性能优化技巧”，实则它是编译期的意图声明。当你写if (unlikely(err)) { /* error handling */ }，你不是在告诉CPU“这个分支很少走”，而是在告诉编译器：“请把错误处理代码挪到主执行流之外，避免污染指令缓存热点”。这背后是内核对现代CPU微架构的深刻理解：分支预测失败代价远高于代码体积增加。所以unlikely()出现的地方，往往对应着真正的异常路径（如内存分配失败、硬件故障），而不仅仅是“概率小”的情况。我在某次调试一个DMA传输超时问题时，发现驱动里把if (dma_mapping_error())写成了likely()，结果编译器把错误处理代码塞进了高速缓存热区，反而加剧了超时——这就是没吃透“语言惯性”的代价。

3.2 第二阶：建立“资源生命周期地图”（Resource Lifecycle Mapping）

内核里没有“new/delete”，只有“alloc/free”、“get/put”、“add/del”。每个资源都有严格定义的创建、使用、释放三阶段，且阶段间有强约束。以struct device为例：它的生命周期由device_register()启动，由device_unregister()结束，中间必须经过device_add()才能被用户空间看到。但关键在于：device_unregister()不等于立即销毁。它只是将设备标记为“正在移除”，然后触发异步的device_release()回调，最终在引用计数归零时才真正释放内存。这个设计让设备驱动可以安全地在中断上下文中调用put_device()，而不必担心内存被瞬间回收。

实操中，我见过太多因忽略生命周期导致的疑难Bug。比如某次为摄像头模组写驱动，probe()函数里用devm_kzalloc()申请了缓冲区，但在remove()里手动kfree()了同一块内存——结果内核直接 panic。原因？devm_*系列函数注册了自动清理回调，remove()时内核已计划释放，你手动kfree()就造成了双重释放。正确做法是：要么全程用devm_*，要么全程用普通kmalloc/kfree。建立“生命周期地图”的关键是：在写任何资源操作代码前，先在纸上画出它的创建点、所有引用点、所有释放点，并标出每个点的执行上下文（进程/中断/软中断）。这张图比任何注释都管用。

3.3 第三阶：掌握“上下文切换契约”（Context Switching Contract）

内核最危险的坑，90%源于上下文误判。所谓“上下文”，指代码执行时的特权级、抢占状态、中断使能状态、内存映射状态。内核用一套严格的命名和注释规范来标识契约：

• _irqsave/_irqrestore后缀：表示该函数会关闭本地中断，并保存/恢复中断状态寄存器；
• _bh后缀（bottom half）：表示该函数只能在软中断上下文中安全调用；
• atomic_前缀：表示该操作在所有上下文中都保证原子性（通常用汇编实现）；
• rcu_read_lock()/rcu_read_unlock()：表示进入RCU读侧临界区，此时不能睡眠、不能被抢占。

我曾帮某公司排查一个偶发死锁：他们的自定义sysctl处理函数里调用了mutex_lock()，而该sysctl又被proc_dostring()在中断上下文中间接调用。结果就是：中断处理时尝试获取互斥锁，而锁已被进程上下文持有，系统瞬间僵死。根因就是违反了“上下文契约”——mutex_lock()只能在进程上下文中使用，而sysctl处理函数必须假设自己可能在任意上下文中被调用。解决方案不是加锁，而是改用spin_lock_irqsave()或重构为 workqueue 异步处理。记住：内核里没有“万能函数”，每个API都带着明确的上下文护照，用错上下文，就像拿飞机驾照去开潜艇。

4. 实操验证：用三个经典场景检验你的内核心智模型

4.1 场景一：为新传感器添加 sysfs 属性——检验“渐进式演化”与“生命周期”理解

假设你要为一款温湿度传感器添加temperature和humidity两个 sysfs 属性。新手常犯的错误是直接在probe()里写：

// ❌ 错误示范：缺少错误处理、忽略生命周期、破坏演化能力 device_create_file(&client->dev, &dev_attr_temperature); device_create_file(&client->dev, &dev_attr_humidity);

正确做法需分四步：

1. 定义属性结构体（体现演化能力）：

static ssize_t sensor_temp_show(struct device *dev, struct device_attribute *attr, char *buf) { struct i2c_client *client = to_i2c_client(dev); struct sensor_data *data = i2c_get_clientdata(client); // 注意：这里必须检查 data 是否有效，因为 remove() 可能已释放 if (!data || !data->valid) return -ENODEV; return sprintf(buf, "%d\n",>
在 probe() 中注册（绑定生命周期）：
// ✅ 正确：使用 devm_ 系列函数，与设备生命周期绑定 err = devm_device_create_file(&client->dev, &dev_attr_temperature); if (err) { dev_err(&client->dev, "Failed to create temp attr: %d\n", err); return err; // 立即返回，不继续注册其他属性 } // humidity 同理...
在 remove() 中清理（自动完成，因用 devm_）：
// 无需手动 device_remove_file()！devm 机制会在 device_unregister() 时自动清理
预留演化接口（为未来扩展埋点）：
// 在 sensor_data 结构体中预留 struct sensor_data { int temperature; int humidity; bool valid; u8 reserved[64]; // 为未来新增字段预留空间，避免结构体大小变化破坏ABI };
注意：DEVICE_ATTR_RO宏内部已包含__ATTR定义，它确保属性文件权限为0444（只读），避免用户空间误写导致驱动状态混乱。这种细节不是“防君子”，而是防止脚本批量操作时的误伤。
4.2 场景二：中断处理函数中的内存分配——检验“可预测性”与“上下文契约”
某驱动在中断处理函数irq_handler_t中调用kmalloc(GFP_KERNEL)，结果系统在高负载时频繁卡死。问题根源是：GFP_KERNEL允许睡眠，而中断上下文禁止睡眠。正确解法不是换GFP_ATOMIC（它可能分配失败），而是重构数据流：
中断处理函数只做最轻量工作：
static irqreturn_t sensor_irq_handler(int irq, void *dev_id) { struct sensor_data *data = dev_id; // 仅记录中断发生，唤醒下半部 schedule_work(&data->work); // workqueue 在进程上下文中执行 return IRQ_HANDLED; }
将耗时操作移到 workqueue：
static void sensor_work_func(struct work_struct *work) { struct sensor_data *data = container_of(work, struct sensor_data, work); // 此时可在进程上下文中安全使用 kmalloc(GFP_KERNEL) struct sensor_reading *reading = kmalloc(sizeof(*reading), GFP_KERNEL); if (!reading) return; // 读取传感器数据、解析、上报... kfree(reading); }
这个重构看似增加了代码量，但它把“不可预测的内存分配”从硬实时中断路径，移到了可调度的进程路径，彻底消除了卡死风险。这才是内核哲学的落地：用数据流的分层，换取执行路径的确定性。
4.3 场景三：多核平台上的共享计数器——检验“简单性”与“数据流驱动”
你需要统计某个硬件事件在所有CPU上的总发生次数。新手常写：
// ❌ 错误：全局变量 + spinlock，锁竞争严重 static unsigned long global_counter; static DEFINE_SPINLOCK(counter_lock); void event_occurred(void) { unsigned long flags; spin_lock_irqsave(&counter_lock, flags); global_counter++; spin_unlock_irqrestore(&counter_lock, flags); }
在32核服务器上，这个锁会成为性能瓶颈。内核的标准解法是percpu_counter：
// ✅ 正确：利用数据流局部性，牺牲一点精度换取可扩展性 static struct percpu_counter event_counter; static int __init sensor_init(void) { return percpu_counter_init(&event_counter, 0, GFP_KERNEL); } void event_occurred(void) { percpu_counter_inc(&event_counter); // 无锁，操作本地CPU计数器 } static ssize_t counter_show(struct device *dev, struct device_attribute *attr, char *buf) { s64 count = percpu_counter_sum(&event_counter); // 需要时聚合所有CPU值 return sprintf(buf, "%lld\n", count); }
percpu_counter的精妙在于：它把“全局一致性”这个强需求，降级为“最终一致性”。每个CPU维护自己的本地计数器，percpu_counter_inc()是纯本地操作，无锁无竞争；只有在用户空间读取总数时，才进行一次性的跨CPU聚合。这完美体现了“简单性”——不追求理论上的实时精确，而选择在硬件物理限制（NUMA延迟、缓存一致性开销）下最经济的实现。你看到的“精度损失”，其实是内核主动放弃的、对系统整体吞吐量无益的计算负担。
5. 常见误区与避坑指南：那些没人明说但人人踩过的坑
5.1 误区一：“看懂代码=理解设计”——混淆实现细节与设计意图
很多开发者花大量时间跟踪fork()的2000行源码，却忽略了fork()存在的根本原因：POSIX标准要求进程必须支持“写时复制”语义，而内核选择用copy-on-write技术来满足，而非真正复制内存。前者是“怎么做”，后者是“为什么这么做”。我见过最典型的案例：某团队为提升容器启动速度，试图在fork()中禁用COW，直接分配新页框。结果不仅没提速，还因破坏了mmap(MAP_PRIVATE)的语义，导致共享库加载失败。他们解决了“代码问题”，却违背了“设计契约”。
实操心得：每次阅读内核代码前，先问三个问题：① 这个功能要满足哪个外部标准（POSIX/Linux ABI）？② 它要应对哪些硬件约束（x86 TLB size/RISC-V MMU特性）？③ 如果去掉它，哪些现有用户空间程序会崩溃？答案比代码本身更有价值。
5.2 误区二：“用最新内核=最稳定”——忽视演化路径的断裂风险
企业环境常盲目升级到最新 LTS 版本，却忽略了一个事实：内核的稳定性不取决于版本号，而取决于你使用的子系统是否在该版本中完成了完整演化闭环。例如CONFIG_BPF_JIT在 5.10 中默认启用，但某款国产GPU的驱动依赖的旧版drm子系统，在 5.10 中尚未完成 JIT 适配，导致图形渲染随机崩溃。我们当时的选择不是退回 5.4，而是打一个上游已合入、但尚未随版本发布的修复补丁（commit id:a1b2c3d...），并将其作为构建时的必要补丁。
表格：内核版本选择决策参考
评估维度
安全建议
实操工具
硬件支持
优先选择该硬件厂商官方认证的内核版本（非最新版）
查阅芯片厂商 BSP Release Notes
安全更新
LTS 版本每3个月发布一次安全补丁，但需确认补丁是否覆盖你使用的子系统（如nvme）
git log --oneline v5.10..v5.10.123 drivers/nvme/
生态兼容性
Docker/Kubernetes 对内核特性的依赖有明确版本要求，需交叉验证
kubectl version --output=yaml查看 kubelet 所需内核最小版本
5.3 误区三：“调试=加printk”——低估日志对实时性的影响
在实时性敏感场景（如音频驱动），printk()不是调试工具，而是性能杀手。printk()会获取console_lock，在多CPU系统上造成串行化瓶颈。某次为声卡驱动调音延迟，我们加了10个printk()，结果音频播放从44.1kHz 降到 32kHz。正确方法是使用trace_printk()（编译时关闭）、ftrace动态追踪，或更激进的——用perf直接采样硬件事件（perf record -e cycles,instructions,cache-misses -a）。
注意：trace_printk()的输出不经过 console，而是写入 ring buffer，对实时性影响极小，但需配合trace-cmd工具读取。它应该成为你printk()的默认替代品，除非你明确需要 console 输出（如启动早期调试）。
5.4 误区四：“驱动写完=工作结束”——忽略内核的“静默契约”
内核驱动不是独立程序，它必须遵守一系列静默契约：
电源管理契约：若驱动未实现.suspend/.resume回调，内核在系统休眠时会强制调用pm_runtime_force_suspend()，可能导致硬件状态丢失；
热插拔契约：PCIe 设备热拔时，若驱动未正确处理remove()，残留的struct device可能阻塞后续同型号设备枚举；
内存管理契约：使用dma_alloc_coherent()分配的内存，必须用dma_free_coherent()释放，混用kfree()会导致 IOMMU 映射泄漏。
这些契约不会在编译时报错，但会在特定场景下引发难以复现的偶发故障。我的经验是：每个新驱动开发完成后，必须执行“契约压力测试”——在目标平台上连续执行100次echo mem > /sys/power/state（休眠唤醒），再执行50次 PCIe 设备热插拔，最后用cat /proc/meminfo | grep DMA检查 DMA 内存是否持续增长。只有通过这三关，才能认为驱动真正“融入”了内核生态。
6. 从今天开始构建你的内核心智模型：一份可执行的行动清单
不要试图一次性消化所有内容。内核心智模型的建立，本质是认知习惯的重塑。我给你一份可立即执行的7天行动清单，每天只需30分钟，坚持下来，你会发现自己看代码的视角彻底改变：
Day 1：解剖一个struct
选include/linux/skbuff.h中的struct sk_buff，不看代码实现，只做三件事：① 列出所有字段名；② 为每个字段写一句“它回答了数据流的哪个问题？”（如skb->len回答“当前数据长度是多少？”）；③ 找出3个字段，说明它们如何体现“可预测性”（如skb->data_len为何必须是unsigned int而非int？）。
Day 2：追踪一个ioctl
用strace抓取ls -l /sys/class/net/eth0/的系统调用，找到ioctl调用。然后在内核源码中定位其处理函数（通常在drivers/net/下），画出从用户空间传入的struct ifreq，到内核如何解析、校验、执行的完整数据流图。重点标出所有copy_from_user()和copy_to_user()的位置——它们是用户空间与内核空间的数据闸门。
Day 3：重写一个printk
找一个驱动中现有的printk(KERN_INFO "...")，将其替换为trace_printk("...")。编译内核，用trace-cmd record -e 'sched:sched_switch'启动追踪，再触发该驱动行为，最后用trace-cmd report查看 trace。对比printk和trace_printk在 trace 中的出现位置和耗时，体会“数据流”与“控制流”的区别。
Day 4：绘制生命周期图
选drivers/i2c/busses/i2c-designware-main.c中的dw_i2c_probe()函数，用纸笔画出：①devm_kzalloc()分配的每个结构体；② 每个结构体的init、use、destroy三个阶段分别在哪些函数中；③ 每个阶段的执行上下文（probe()是进程上下文，interrupt handler是中断上下文）。
Day 5：验证一个宏
深入研究include/linux/compiler.h中的__user宏。用gcc -E预处理一个含__user的简单文件，观察生成的宏展开结果。然后写一个测试程序，故意将用户空间指针传给标有__user的函数参数，看编译器是否报错——这会让你真正理解“类型安全”在内核中的物理存在形式。
Day 6：模拟一次演化
假设你要为struct device新增一个u64 boot_time_ns字段（记录设备首次探测时间）。不改内核代码，只做：① 设计向后兼容方案（如用reserved[]扩展）；② 写伪代码说明如何在device_register()中初始化该字段；③ 设计用户空间读取接口（sysfs还是debugfs？为什么？）。
Day 7：复现一个经典Bug
在虚拟机中编译一个故意违反上下文契约的驱动（如在中断处理函数中调用mutex_lock()），触发 kernel panic。然后用crash工具分析vmcore，定位 panic 发生在mutex_lock的哪一行汇编，并对照Documentation/locking/lockdep-design.txt理解 lockdep 如何检测到这个错误。
这份清单不追求“学会”，而追求“触感”——让你的手指记住container_of的括号顺序，让你的眼睛习惯在#ifdef块中寻找硬件差异线索，让你的大脑在看到GFP_标志时自动关联到执行上下文。内核不是用来“学”的，是用来“长”在身上的。当你某天在咖啡机旁脱口而出“这个需求得用 workqueue 拆解，不然中断延迟保不住”，你就知道，心智模型已经悄然成型。
我个人在实际开发中发现，最有效的学习方式不是盯着屏幕看代码，而是动手改一行，然后立刻验证它破坏了哪条铁律。比如把spin_lock_irqsave()改成spin_lock()，看系统在什么负载下开始丢中断；把percpu_counter改回全局变量，用perf测量锁竞争耗时。每一次“破坏性实验”，都比十次阅读更能刻进肌肉记忆。这个专栏后续会深入调度器、内存管理、RISC-V适配等具体战场，但所有内容都将锚定在这四条铁律之上——因为真正的内核高手，不是代码写得最多的人，而是最清楚“为什么不能那么写”的人。