企业官网建设流程全解析

说实话，在拿到录取通知书、看到专业培养方案的那一刻，我心里想的是“我的人生要开始变得很酷了”。作为一个把电脑当游戏机用了整个高三的大一新生，我幻想中的编程世界，是敲几行代码就能让东西动起来、弹出来、或者变成游戏画面。结果开学第二周，当老师把编译器的界面投到幕布上，让我敲下人生第一行printf("Hello, World!")的时候，我才意识到事情没那么简单——报错提示是红色的，光标是一闪一闪的，而我的脑子是空白一片的。这就是我初入编程世界最真实的起点：一边觉得自己已经站在了未来面前，一边连保存文件到哪个文件夹都要问同桌。

这篇文章其实就是一个大一新生的自白，记录我从“看代码像看天书”到“能独立写完几十行的小作业”、从“一编译就红一片”到“学会看报错信息自己解决问题”的真实过程。里面没有高深的理论，也没有半个月冲进大厂的逆袭剧本，只有我在C语言课上、在图书馆里、在宿舍深夜的台灯下踩过的坑、流过的汗和总结出来的一点一滴的经验。如果你也刚刚起步，或者你正打算迈入编程的世界，我希望这篇文字能让你知道：你不是一个人在面对那些看不懂的符号，那些编译不过的痛苦和觉得自己不适合编程的瞬间，都是这个阶段标配的一部分，天塌不下来，代码也总能调通。

1. 最开始，我把编程想得太浪漫了

1.1 以为编程就是“想象力变现”

我产生学编程的念头，最早不是因为任何职业规划，纯粹是被那些“黑客在黑色屏幕上飞速敲击键盘、一回车就能突破所有限制”的电影画面给骗了。我那时候的理解是：编程 = 想象力，只要脑子里有想法，代码就会像魔法一样自动变成现实。

后来上了第一节程序设计课，老师花了整整两节课讲“数据类型”“变量”“常量”“表达式”，我坐在阶梯教室里一开始还在记笔记，二十分钟后就开始走神了。我清楚地记得那节课的作业之一是定义一个整型变量x，再定义一个浮点型变量y，然后把它们的和打印出来。我在想，这种东西有什么意义？我定义它、它让我定义它，这和我想象中点几下鼠标就能做出一个会跳的小人，差距大得让我怀疑自己是不是选错了专业。

这种落差感是每一个大一新生几乎都会遇到的。你以为编程是创造世界，实际上最开始的一两个月，你只是在和计算机进行一种极其机械、极其严格、极其无趣的对话。你少写一个分号，它就罢工；你把==写成了=，它就用一种诡异的逻辑惩罚你半天；你明明觉得逻辑没问题，它却能把1 + 1算成2之后再告诉你1 + 2的结果不对——因为你的变量被覆盖了。

1.2 第一次对着空白的文件发呆半小时

我记得特别清楚，有一次上机实验课，老师让写一个程序：输入三个整数，输出其中最大的一个。题目不长，要求也不高，但我盯着空白的源文件看了足足二十五分钟。我脑子里有一个大概的正确思路，但就是不知道该从哪里下手：是先声明三个变量？还是先写输入？中括号要不要打在同一行？函数体里到底该写什么？printf和scanf的格式到底是不是互相匹配？

那种感觉非常微妙。就像你拿到了一份中文菜谱，每个字都认识，但你就是不知道“适量盐”是半勺还是一勺，不知道“锅中倒入少许油”是冒着烟放还是冷油就下锅。等到我战战兢兢地写了一小段，编译，屏幕上跳出七八个error，我看不懂任何一行英文，于是把代码涂改得面目全非，然后继续发呆。

那天晚上回到宿舍，我打开视频网站上存好的编程入门课，跟着一瘸一拐地重新写了一遍，才发现问题出在：我根本没用&取地址符去配合scanf。我在高中完全没有接触过指针概念，甚至没有听说过“一个变量在内存里是有地址”的这件事。老师讲的时候可能默认我们已经懂了，但我坐在台下是真的愣住的。这算是我在编程世界里撞上的第一堵墙：不是题的难度，而是知识背景的断层。你以为老师在讲scanf，实际上他默认你已经知道函数需要往内存地址里写数据。

大一新生学编程，最难熬的往往不是代码本身，而是这种无处不在的“默认你知道”。习惯了之后我才学会一种方法：凡是听不懂的关键词，立刻记到手机备忘录里，下课自己查，宁可慢一点也要把每一个名词的坑填上，不然后面的内容就是在一片沼泽上盖房子。

2. 大一这一年，我到底都学了什么、用什么工具

2.1 第一门语言：C语言，又爱又恨的对象

我们学校的第一门语言是C语言，这几乎是国内多数计算机相关专业新生的共同开局。关于“为什么大一不直接学Python”，我后来想明白了。Python确实更好上手，但C语言逼着你去面对计算机的底层逻辑：类型、字节、指针、内存、栈区堆区、编译链接。它不惯着你，它就是要你搞清楚“你的数据到底存在哪里、在内存里长什么样、该用盒子还是指针去描述它”。

当然，明白这个道理是期中的事。刚开始学C语言的三周，我一度以为自己专业课老师是故意来教会我什么叫“绝望的”：字符串要用字符数组存、判断要用==、赋值用=、%d和%f对应不同的变量类型、整型和浮点型做除法的时候会整个把小数部分扔掉。

我记得自己第一次顿悟是在学完循环之后写一个九九乘法表。那是我人生中第一次独立写出一个有输出、有格式、有嵌套逻辑、能跑出正确结果的程序。虽然这个程序在会写代码的人眼里简单得不值一提，但当屏幕上真的按阶梯排列显示出那四十五个算式时，我激动得把室友喊醒看了一遍。那种从零到一的感觉，很难用“快乐”两个字笼统地概括，它更像是你朝着一扇一直锁着的门踹了一脚，门不仅开了，里面还透着一股光。也就是从那一刻起，我开始不再讨厌C语言，甚至还主动多找了几道循环题来练手。

如果你也是正在被C语言折磨的大一新生，我给你一句实在话：务必重视它，但别因为它枯燥就觉得自己没有天赋。C语言给你建立的那套内存、指针、数组观念，会在你后面学任何语言时反复地救你一把。你可以抱怨它得不偿手，但你需要它作为地基。

2.2 开发环境的折腾史：Dev-C++、Code::Blocks与命令行

大一上学期用哪个工具写代码，这事儿看似不起眼，实际上直接影响学习心情。我们学校机房装的是某款教学版IDE，界面老、补全弱，但字大、按钮显眼，对纯小白来说反而没有心理压力，起码打开就能写。我一开始就在那个老旧的IDE里写练习代码，觉得一切正常，直到后来同一宿舍的室友在用另一款现代化的IDE，它带代码高亮、有补全、有错误提示下划线，我看了一眼瞬间觉得自己用的是小霸王学习机。

所以大概在国庆节之后，我开始折腾自己的开发环境。先装了某主流现代化IDE，新建C项目、写代码、编译都在里面完成。但是因为我自己对工程的概念还不理解，甚至不懂工作目录是什么意思，经常出现一种情况：在IDE里能跑，但把源代码文件发到同学邮箱里，对方打开之后却跟我说找不到文件、编译不了。我那时候才知道，IDE帮你把很多东西自动打理好了，但也让你对真实世界里的编译过程一无所知。

在同学的指导下，我开始试着用命令行去编译C文件。第一次在终端里敲gcc hello.c -o hello，看着文件夹里真的生成了一个可执行文件，再敲./hello运行出输出，那种朴素的、原始的、自己掌控全流程的感觉，给了我非常深的印象。我强烈建议所有大一新生，至少尝试一次脱离IDE去亲手编译、运行一个程序。不是让你永远用命令行，而是让你知道：IDE是工具，不是魔法。

环境折腾这件事，本身也算一种编程学习。你会遇到环境变量配好了但终端不认、编译器装好了但代码在IDE里能跑命令行却报错、甚至系统预设的安全权限拦截了某个程序执行，这些坑每一个都能让你多花半小时，但每一个也都在悄悄锻炼你解决问题的能力和耐心。到了下学期，我已经能帮舍友排查一半以上的“为什么我电脑上跑不起来”的问题了，这种经验反而是课本不教、但在编程世界里特别管用的生存技能。

2.3 从“敲代码”到“编程思维”的真正转变

大一上学期，我一度把“编程能力”理解成“打字速度和语句背诵量”。谁背下来的关键字多、谁能在不看课本的情况下默写出冒泡排序，谁就厉害。这种想法在我第一次做大作业、连续写了三天到凌晨之后就彻底变了。

那个大作业是一个模拟简单学生成绩管理系统，要求能录入、能修改、能按成绩排序、能输出统计结果。功能不难，但需要写的函数很多，牵涉到结构体数组、排序、菜单循环和格式化输出。我周五下午开工，第一版写了一整个晚上，写到两百多行就再也加不动了：因为我把它全写在了main函数里面，变量一团乱，函数之间互相调用层层嵌套，我改了一个循环，另一个循环就莫名其妙地跟着出错，打印出来的结果有时候正常，有时候乱掉，完全看运气。

那是一个特别难熬的周末。后来我在一次正常的浏览技术文章时，看到一句话：“如果一个函数的代码块超过一屏，你就要考虑拆分它了。”这句话像脑袋上挨了一棍。我回头看看自己那坨纠缠在一起的代码，突然意识到：不是我没认真写，而是我根本还没学会用函数去拆问题。当我试着把“录入”“排序”“显示菜单”分别抽成一个个独立的函数，每块功能各司其职、参数清晰返回明确之后，同样一个程序，整理后也不过两三百行，但逻辑清晰得我自己都能逐一解释。

这才是我理解的“编程思维”的真正起点：把一个大问题拆成很多小问题，逐个小问题解决掉，最后拼起来变成能跑的完整系统。它不是靠背代码背出来的，而是在一次次被自己的代码恶心到之后，被迫学会的。编程不是比谁记得多，而是比谁会拆解、会用工具、会查资料、会设计流程。这些能力听上去和代码无关，但恰恰是写代码能不能走得远的分水岭。

3. 大一踩过的坑，每一个都值得写进避坑手册

3.1 编译报错不是灾难，而是你的向导

几乎每个大一新生在第一次看到编译器的报错英文时，都会下意识地恐慌。我也一样，看到红色的error就觉得自己犯了大错，赶紧找同学假装不经意地问“这个是什么意思”，其实只是想让他帮我改一下。直到后来有一次，某位靠谱的学长跟我说了一句话：“报错不是骂你，它在告诉你它需要什么。”

从那以后，我开始强迫自己在报错面前停下来，不急着删掉代码，而是先看两样东西：报错出现在第几行，报错的那条英文在说什么。比如expected ';' before 'return'，翻译过来就是我漏了一个分号；undeclared identifier，就是我用了还没声明的变量。我一查一改，慢慢地，报错在我眼里从“天书”变成了“提示”，从恐惧对象变成了调试向导。

建议你从现在开始培养一个习惯：编译报错之后，第一反应不是截图发给别人，而是先把报错的英文原句复制下来，用翻译工具或者直接搜索报错信息。很多时候，你搜到的第一条就是你这个问题已经有无数人踩过并解决的帖子。编程世界的规则就是这样：你遇到的百分之九十九的报错，前辈们都遇到过，而且解决方案就明晃晃地放在那里。

具体实操上，我还会在编译器下方开一个“问题列表”面板，不着急按顺序改，而是先按“错误数量”看，一般情况下真正导致编译失败的错误就那么一两个，后面那些error经常是由前面某一个小错误引发的连锁反应。比如你少写一个右括号，后面所有代码在编译器眼里都是乱套的，可能会报出一长串错误。这时候你按顺序改第一个，重新编译，很有可能剩下的就全没了。这个技巧是我在大一下学期才学到的，回头看被它坑掉的头发，真的是一言难尽。

3.2 调试debug：别再靠“猜”了

在没学调试之前，我的代码排错方式极其原始：看不懂结果，就加一行printf打印中间变量，看看到底走到哪一步了。这个方法不能说没用，但效率非常低。一个循环里我可能要加七八个打印语句，输出结果满屏都是，看完还要记得把它们全部删掉，删完再编译又有可能手滑删掉了某行代码。总之就是痛苦。

后来听说IDE里有断点调试功能，我一开始觉得“这是大佬才需要的东西”，自己一个菜鸡去学断点是不是有点不自量力。但有一次，我真的被一个逻辑错误折磨了两个小时，怎么都想不通那个变量在循环里为什么越界了。我抱着试一试的心态，在那个变量使用的位置打了一个红点，然后点了IDE上的“开始调试”按钮，程序停在断点处，我看到了那一瞬间所有变量的当前值，接着一步步单步执行，终于在第六次循环的时候发现：原来是数组下标写成从1开始了，而数组长度只有从0到n-1。

那一瞬间，我几乎要从椅子上跳起来。不是因为问题本身多难，而是我找到了一个比“猜”更可靠的排错手段。此后我就养成了一个极好的习惯：想不通，就开调试；再想不通，就单步走一遍；再不行，就在关键分支里定义带标记的打印。调试不是专家专属技能，它就是你在编程世界里最基本的走路姿势。大一早一点学会用它，你就能早一点少掉头发。

3.3 指针：绕晕你的不是语法，而是“指向”这个思想

C语言里的指针，几乎是所有新生公认的第一道“劝退”门槛。我当时也在指针这里卡了很久，一度觉得自己智力有问题。后来我发现，指针真正难的地方，不是它的写法，而是我们从来没想过“一个变量还可以用一个变量来引用它的地址”。

我打过一个还算贴切的比方，帮自己也想帮助其他同学理解指针：内存就像一排带门牌号的旅馆房间，你定义一个变量a，相当于在某个房间里放了一个数字5。你定义一个指针变量p，相当于在便签纸上写下“5号房里放着数字5”这个信息，然后把这张纸条贴在一个盒子里。指针变量存的是“房间的门牌号”，而不是房间里的内容。int *p = &a就是告诉程序：p这个盒子里贴着“a在那间房”的纸条。当你用*p的时候，程序其实是顺着纸条去找到了那个房间，把里面的数字取出来。

这个类比虽然不严谨，但足以帮我在心理上跨过那道坎。等你真正理解了指针，你会发现后面的数组、链表、字符串、动态内存分配，全都连成了一条线，因为它们的底层都在做同一件事：通过地址找到内容。

关于指针，我还有一个更加实际的建议：别只是看，动手画图。画几个小方框代表变量，再画几个小方框代表指针，用箭头连接起来。然后在纸上模拟一遍p = &a、*p = 10、p++这些操作对箭头和房间里的数字分别会造成什么影响。我在纸上画过十几张这种图之后，指针语法的很多东西突然就通了。编程里很多抽象的概念，动手画一遍就是能比凭空想象理解得快，这是我自己实践下来特别管用的一招。

3.4 抄代码：看起来“很努力”，其实很容易骗到自己

大一还有个特别典型的现象，就是看别人博客上的代码、答案，然后照着敲一遍，敲完觉得自己会了。但我后来发现，抄代码这件事，水非常深。你照着打的时候，手在动，眼睛在看，脑子却可能完全处于休眠状态。敲完可以运行，你高兴，关掉程序，两小时后让你再写一遍，你会发现脑子里什么都没有。

我自己的经验是，抄代码不是不行，但一定是“带着目的去抄”，而不是“为了交作业而抄”。什么叫带目的？就是我先把别人的代码看懂，理解每一个函数在干什么、每一行为什么这么写，然后关掉参考，自己从头开始写。写不出来的地方，再回去看那一段，看完合上，继续写。这个过程的每一步都在逼迫大脑主动加工信息，而不是被动接收字符。

在递归、链表、二叉树这些难点章节，我用的就是“三步抄写法”：第一步，完整看懂一遍；第二步，疯狂修改细节（改变量名、改边界条件、调换两个循环的顺序），看它会不会出错、出错后怎么变化；第三步，合上所有资料，自己默写带注释的版本，能写出来才叫真懂。这样折腾下来，虽然比别人慢很多，但每学一个知识点，我是真的把它装进脑子里了，而不是仅仅保存在了硬盘里。

4. 摸索出来的学习方法：不是最牛的，但是最稳的

4.1 只看视频根本不行，动手量才是分水岭

很多新手（包括我）一开始都有一个很不好的习惯：在B站上找一堆入门教程，收藏，坐端正，戴着耳机，从头到尾看得津津有味，感觉自己一直在学习。但看完之后让你写一个程序，你发现连最基本的框架结构都要想半天。为什么？因为看视频是“输入”，而写代码是“输出”，这两个过程用到的大脑区域完全不同。

我后来给自己立了一个硬规矩：看视频不超过二十分钟，就必须停下来动手写一段。哪怕是重复视频里的例子，也要亲手敲一遍，而且尽量不按暂停键对着敲，而是看完一个片段后关掉视频，凭印象写。写不出来再回去看，再关掉再写。这样一来，写写停停，看一个四十分钟的教程，我可能要花两个小时，但效率反而比以前更快。因为动手写的过程，让我的大脑真正开始思考：下一行该写什么？这个变量应该在哪个作用域？这个循环的边界条件到底怎么设？

说实话，这个方法不是最省时间的，但绝对是最让知识留得住的。编程的高手和老手之间的差距，很大一部分不是在智商上，而是在“谁的手底下过过更多真实的问题”。动手次数多了，那些语法和套路会沉淀成肌肉记忆一样的东西，你遇到类似问题的时候，手指直接就能敲出来答案，根本不用想。

4.2 写代码卡住时，先别急着翻书，先画流程图

大一上学期的时候，我一道题卡住了就爱翻书找一样的例题，找不到就想看答案。后来我发现，这个方法会把我的思考能力越养越懒。真正比较进阶的做法是：写代码之前，先不要把注意力集中在“这句怎么写”上，而是集中在“这个程序的逻辑到底怎么走”上。

拿出一张白纸，把题目里要完成的事情拆成步骤。先干什么、后干什么、满足什么条件的时候循环、满足什么条件的时候退出，用最简单的词语写下来。比如“如果输入0就退出循环”“把最大值变量更新为当前输入”“结束后打印求和结果”。这些大白话写出来之后，你观察它们之间怎么套在一起，然后才是把它翻译成代码。

流程图这个工具，我一开始觉得老土，好像是小学六年级科学课才用的东西。但真的上手一次之后，我发现画流程图几乎就是编程思维的外包装。你画着画着，就自然地在用条件判断和循环来思考问题。如果你现在还在频繁“卡在不知道该写什么”，我建议你试一周：先画图，再写代码，哪怕画得潦草至极。你会发现自己写代码的连贯性肉眼可见地提升，因为你在写之前脑子里已经有一张路线图了。

这个习惯还有一个额外的好处：等你后面面对稍微复杂一点的项目题目时，画图能帮你保住大局观，不会被细节淹没。很多学长做课程设计或者参加比赛时，也是靠高层的流程图和模块图去把控整体的，大一就开始练这个习惯，后面自然受益。

4.3 提问也是一门学问：我学会不做一个“伸手党”

不会的时候问学长、问老师、问同学，这本身没错。但大一的我，提问的质量实在堪忧。我经常发过去一张代码截图，然后说：“这个为什么跑不出来？”对方面对几百行代码，既不知道我输入了什么，也不知道我期望的输出是什么，更不知道我在哪一行觉得有问题，根本无从下手。

后来一位靠谱的学长教了我一个“三句话提问法”，我觉得特别适合程序员新手：第一句，我遇到了什么问题；第二句，我为了这个问题做了哪些尝试；第三句，我卡在哪一步、希望得到什么帮助。有一次我在做链表删除结点功能时总出错，我就按这个方法整理：问题——删除结点后遍历时会打印出异常值；尝试——我用printf打印了当前结点和下一个结点的地址，发现在删除中间结点时释放内存的时机不对；卡点——我发现在free临时结点之后，我又去访问了它的next，导致读到野指针。学长一眼就看出了我的问题：应该在free之前先保存好next。这个案例后来成了我脑子里非常牢固的一个知识点，因为我不仅是“问”来的，还是自己排查了一半再问来的。

观察周围编程能力强的同学，我发现他们遇到问题的第一反应永远是：先自己搜索，先自己调试，先自己思考。实在不行了才去问，而且问的时候，会给对方完整的信息上下文。这不仅是情商问题，更是效率问题：你把问题描述得越清楚，别人帮你定位得越快，你自己学到的东西也越扎实。

5. 从代码之外，我关于编程心态和节奏的一些真实想法

5.1 你会反复地觉得自己“不适合编程”

我在大一这一年里，至少有大大小小四五次“我是不是不适合编程”的念头。第一次出现在学指针的时候，第二次出现在写那个复杂的成绩管理系统大作业的时候，第三次出现在面对一道写了两个小时的算法题依然段错误的时候。每一次，屏幕上的错误提示都像一巴掌，扇得我怀疑自己是不是脑子不够用。

后来我看了一句话想通的：编程这件事情，它不考验你“上不上手就有天赋”，它只考验你“遇到问题之后，能不能继续留下来”。一个程序跑不通，不是因为你智商不行，而是因为你对这个问题的认知还缺一块。缺哪块补哪块就行了，跟天赋没什么关系。你会觉得难，是因为编程的反馈极其即时且冷酷，它对就是对、错就是错，骗不了人，这其实是编程最公平的地方，也是它让人最挫败的地方。

为什么会反复自我怀疑？因为编程里的“新东西”太多了，而且从不会因为你上一个知识点学得好，下一个就会自动变得轻松。你可能刚弄明白指针，又被函数的传参方式弄晕；刚把链表整明白了，又迎来了递归。这本质上是认知升级的必然阵痛。遇到挫败，我的建议是：允许自己休息一下，出门吃顿好的，或者干脆睡一觉，第二天再来看同样的报错，你可能会发现它是一个特别简单的问题。这种“睡一觉就会了”的经历，我身边不少同学都有过，因为大脑在你放松的时候也在后台整理信息。

5.2 用“小目标、小项目”持续喂饱自己的成就感

我之所以没有大一中途就摆烂放弃，很大一个原因是我学会了为自己创造成就感。具体做法就是：不盯着那些特别难的算法题，而是在课本作业之外，给自己安排一些“跳一跳够得着”的小项目。

比如在我学完C语言数组和字符串之后，我给自己写了一个“简易密码生成器”：输入几个关键词，程序自动组合、打乱、插入符号，生成一个看起来非常随机的密码。功能特别简陋，但我从头到尾自己设计思路、自己写代码、自己调试成功，那种满足感比做对十道课后题都强烈。后来又写过一个“简易登录系统”，没有数据库、没有图形界面，就在终端里提示输入用户名密码，用文件保存帐号信息，要求有注册、登录、修改密码三个功能。这个项目让我真正用上了结构体和文件操作，做完之后我用它给我的游戏账号设了个密码，回头满脑子都是“这可是我自己写的东西”。

小项目的好处有三个：一是让你完整经历一个“从需求到设计到编码到调试”的闭环；二是让你收获课本之外的、属于自己主动学习的成就感；三是在你期末或者做课程设计时，你会发现，你早就在别处锻炼过类似的工程能力了。我给所有大一新生的建议都是：不要等到期末大作业才动手写一个完整的程序，平时一个月给自己一个小目标，哪怕只是“做一个随机出题的口算练习器”，也要能跑起来、能自我使用。这种正反馈循环，是支撑你走完枯燥阶段的最佳燃料。

5.3 给和我一样站在起点的你：几条最实在的建议

最后整理几条我对大一新生学习编程的建议，都是我自己走了弯路之后才总结出来的：

第一，尽早养成动手的习惯，哪怕一天只写十行代码。编程是手艺活，光看不练，等于看菜谱学做菜。哪怕今天只写一个“输入半径求圆面积”的小程序，也能让你对手感保持熟悉。

第二，认真学好C语言，但不要止步于C语言。C语言帮你建立最核心的计算机思维：类型、内存、指针、流程控制。但如果你学完C语言以后发现自己对图形界面、Web或数据处理更有兴趣，大胆往那个方向去尝试，大一本来就是用来试错的，试出来才知道你更喜欢什么。

第三，不要因为“别人写代码很快”而焦虑。很多看起来很快的同学，可能在大一之前已经学了一年甚至更久。你的赛道是自己，和昨天的自己比较就够了。编程不是短跑，是马拉松，起步慢一点没关系，走得远才重要。

第四，有问题就搜索，搜索不到就问，但问得要有质量。把“为什么不行”改成“我做了什么样的尝试、卡在哪一步”，你得到的帮助会有效得多。这个习惯，不仅对编程有用，对你的整个大学生活都会有用。

第五，用博客记录你的学习脚步。哪怕只是把今天学的一个知识点、踩到的一个坑、解决的一个小问题写成几百字的文章，坚持下来就会发现，这些文字不仅是复习资料，也是你从一个茫然新生一步步走过来的真实证据。写博客这件事，本身就是在教你怎么把输入变成输出，而编程的最终目标，往往也正是把输入变成有用的输出。