始终都是写对于技术的一些货色，素来没想过我会写一篇与技术没什么关系的文章，因为在之前的我看来，这种文章齐全就是假大空
技术至上？
三年前我毕业进入第一家公司，集体很水的技术能力让我常常在理论的开发工作中顾此失彼，于是就想着肯定要尽快晋升本人的技术水平，每天都在公司待到很晚，除了做需要就是自我学习，在这种状况下，我简直所有能坐在电脑前的工夫都用在了技术上，这就造成了一种结果，那就是我只关怀技术方面的货色，其余的我一律不论，并且越来越重大
评审需要的时候，我不关怀 pm 想要做什么，也不关怀需要的目标是什么，更不关怀是否是不合理的需要，我只思考怎么从技术上实现 pm 的需要，哪怕是再简单再不合理的需要我也肯定要用我的技术手段去实现，甚至以此为荣，我认为这是体现我集体能力的形式，有些时候我的组长因为思考到一些实现比较复杂，被动给我说一些简略的实现计划，我反而心田还有点鄙视，感觉组长太老油条了，什么简单需要，不存在的，多给我一天的工夫我就能给你实现进去
我置信很多做技术的小伙伴，都跟我有过相似的想法，然而三年过来了，回头想想，再思考一下当初，当初的我更想学习一些跟技术不那么相干的货色，比方业务
技术还是业务？
相辅相成
已经的我认为，技术和业务就是两条不相干的路，我投入在业务上的工夫多了，那么在技术上的工夫必然缩小，与其技术、业务两手抓，做出两个 50 分的成绩，我作为一个技术人员，不如只抓技术，争取做出一个 100 分的成绩来，但实际上这种想法有点天真
首先，除非你天才异禀，否则很难将一件事件做到极致的 100 分，甚至 80 分都很难；其次，技术跟业务并不抵触，破费一些工夫在推敲业务上，并不会缩小多少你在技术上的投入度，相同的，二者是相辅相成、互相促进的关系，是 1+1 大于 2 的组合
因为可能发现业务的痛点，所以想用技术去解决，带着明确的目标去学习与尝试，必然会有更高的效率；因为有了足够强的技术，所以可能解决更大的业务问题，取得更多的成就感
如果你没有做业务的被动意识，而是被业务方赶着走，这种行为就是搬砖，反之，如果是你推着业务走，让业务方因你而扭转，那么就是你赋能了业务
常常看到一些三到五年工作教训的前端很迷茫，明明晓得路曾经走到底了，却不晓得下一步该怎么走，于是开始尝试着去扭转，但路子可能走得不太对，例如看 Flutter 比拟火，所以跑去学 Flutter，看到 WebGL 可能有前途，于是跑去学 WebGL，甚至有的人跑去学 java/python
不是说这些尝试新事物的行为不好，相同的，很好，敢于尝试敢于口头无论什么时候都是值得激励的事件，然而得明确你做这些事件的目标，考虑一下 ROI，比方，你看好 Flutter 将来的倒退，并打算好未来投身于 Flutter 畛域，于是先本人学起来，打好根底为未来进入一个 Flutter 团队，甚至是在本人的团队内推广 Flutter 做好筹备，那么显然是正确的思路
然而如果你只是感觉当初的工作到瓶颈了，感觉大家都在吹 Flutter，反正本人也不晓得要干啥，那就跟风学学吧，或者可能未来就派上用场了，到时候本人一举成名，那么这种思路其实就有点跑偏了，Flutter 的确能带给你新鲜感与学习到新货色的成就感，但这并不能解决你目前工作碰到瓶颈的问题，你只是抉择去回避它而已，leader 给你打绩效并不会看在你学会了 Flutter 的体面上，就手下留情，除非你团队真的在用 Flutter 并且你也参加其中做了奉献了
同样的，作为一个前端问如果会一点 java/go 会不会更有竞争力？我的答案是，聊胜于无（会一点当然最好，但不会也没关系）
你毕竟是前端，如果在前端面试的时候，连前端的基础知识都答不好，你哪怕会背 Spring 源码又有什么用？而如果你能做到无论是根底题、算法、我的项目教训都对答如流，跟面试官谈笑自若，谁还关怀你是否晓得什么是高并发？
拓展壁垒
技术这条路能够很广阔，但对于绝大多数人绝大多数场景来说，可能被理论应用到的技术只是一小部分，特地是前端，相比于后端、算法来说，技术含量较低，更偏向于技术的广度而非深度
可能从业三五年的 C++ 程序员都还会写出有语法错误的 C++ 代码来，但在前端很难产生这种事件，略微勤快点的应届生毕业半年就不该再写有语法错误的前端代码了，有 bug 基本上也都是业务逻辑 bug，一个五年工作教训的C++ 程序员和一个只有一年工作教训的 C++ 程序员，他们的技术水平可能有着实质上的差距，但如果换成前端程序员，很可能两人的技术水平就是差不了多少了
然而很显然，就算是前端程序员，咱们个别状况下还是会认为五年工作教训的会比一年工作教训的能力更强，技术水平可能二者差不了多少，差的是其余方面
技术广度吗？
可能不是，有较大技术广度的人在做技术选型的时候，能够有更多的抉择与搭配，但这种能力并不是必不可少的，公司团队作战，很少会因技术栈的抉择而产生困惑，你或者会因为从业工夫较长，所以学会了更多的技术，例如 React Native、Flutter、WebGL 等，但这些更多地是赋予你切换技术栈的能力而非减少你集体总体的技术实力，如果你公司不必 React Native、Flutter、WebGL，那么你会这些也没多大用，也没人会关怀
如果你公司真的就用这些技术了呢？不好意思，这些又不是什么很难的货色，并不存在技术上的循序渐进，给一个应届生一段时间，他也能学会，个别状况下，一个部门或者团队也不可能用很多种技术栈，技术广度达到肯定水平之后，再持续往上减少的意义只会越来越小
技术深度吗？
或者是
然而这个很难，还是后面说过的话，除非你真的是善于技术，否则你很难有深刻的机会，特地是前端这个畛域，99.9%（可能须要在小数点前面再加几个 9 才符合实际）以上的场景，基本不须要思考什么深度，也基本不须要思考什么性能什么优化，我切实是想不到哪些前端的工作场景下，会须要用到编译层面或者操作系统层面的技术攻关
做出（留神是做出不是会用）小程序或者是做出 React 这种级别的货色，对于前端技术的确是一个重大考验，然而绝大部分人跟这些基本就没啥关系
真正须要深刻到底层，比方编译层面或者操作系统层面，这种曾经不能称为是前端开发了，而能深刻到这个境地的技术人员，大概率也不会是前端出身
工作教训？
是，也不是
如果你工作三年，只是循序渐进地搬了三年砖，那么你可能只是一年的教训又被你反复了两年而已
真正好的工作教训该当是继续学习与提高的，不仅限于技术上的提高，如何写好易于保护的代码、如何用技术能力保障业务的稳定性、如何引领新人疾速融入团队，都是不可或缺的货色，想要取得这些能力，须要工夫，但更须要你的被动摸索与实际，而这些是无奈速成的货色，也是你作为一个技术老鸟，能跟应届生真正拉开差距的中央
而无论是技术水平、技术广度、工作教训，它们之所以有价值，归根结底，还是因为它们都有服务业务的能力，所以一切都是围绕着业务开展的，既然无奈防止，那么天然是越早学会游戏规则越好
什么是业务
在前三年，常常有资格更高的共事跟我提起业务这个词，听得多了，我有时候也想去理解它，但总是发现这个货色太扑朔迷离了，编程语言的语法、关键字、设计模式、算法我都能够实实在在地看到并使用，但业务到底是什么？我怎么学？我又该怎么去关注业务？
总之很苦恼，老是有人跟我说业务，但我却无从下手，硬着头皮去模拟，最终也只是学了个皮毛，于是逐步放弃
目前在第二家公司入职的团队，相比于之前来说，业务压力大很多，简直没法再像之前那样优哉游哉地搞本人的技术钻研，然而在这种环境下，反而减速晋升了我对于业务的了解，也明确了为什么之前那么多人跟我说业务很重要，但没有一个人能教会我到底什么是业务，因为这个货色真的很难说分明，或者换句话说，其实每天都有人跟你说什么是业务，但因为你本人自身无奈领悟，所以你感觉他们什么都没说
在绝大部分状况下，技术都是要为业务提供服务的，这句话蕴含着两层意思
第一，技术的惟一目标就是撑持业务
第二，业务并不仅由技术撑持，还蕴含了其余很多方面
业务是一个商业公司的命根子所在，而技术只是撑持业务的要害之一，所以业务真的很重要
那么，什么是业务其实也就很好了解了，你的技术所服务的就是业务，而你可能让业务蓬勃发展的所有正向能力（包含但不仅限于技术能力），都是业务能力
前端如何赋能业务
必定有人会吐槽我说了半天还是啥都没说，没错，的确是这样，对始终不明确业务是什么的人来说，他人说得再多也很难了解，对于曾经了解的人来说，业务就是业务，基本没什么可说的，可能真的就须要你本人领悟才行，或者某一天你本人就忽然明确过去了
很难说分明业务这个词到底是什么，但工作中处处是业务
前端如何赋能业务的话题比拟大，但具体的例子却很多
经营页面主动搭建
经营伎俩对于 C 端产品来说是很重要的，经营迭代的速度也是影响产品倒退最间接但也是最实用的关键因素之一，比方天猫 618 盖楼流动，美团的满减流动等，这些都是很常见的经营伎俩，简直任何直面 C 端用户的产品都少不了这些
而这些经营流动往往是少不了各种各样前端层面的用户玩法，能够说是比拟依赖前端的一个业务了，那么作为一名前端开发工程师，如果你的指标只是实现业务方提过来的具体的经营需要，当然也算是合格了，毕竟是实现了本人职责，但可能还不够
来一个经营页面你就做一个经营页面，来两个你就上两次线，难度倒是没什么难度，就是防止不了要走一遍整套开发流程，于是聪慧的人就想到，是否能够把这种固定门路搬砖的行为自动化，于是经营页面主动搭建的概念就进去了，当前经营页面的开发与上线都不须要研发参加了，间接让经营来搞定，又快又稳又好，以前一个经营流动须要评审、排期、开发、验收、上线等多个流程，当初简化到只有验收和上线两个节点，极大地提高了生产力，这就是对业务的胜利赋能
那么你能做什么呢？
业内出名的经营页面主动搭建我的项目有很多，例如阿里云凤蝶、阿里飞冰等，然而这些不肯定齐全适宜你的公司，因为经营页面跟具体业务是强相干的，特比是 C 端，业务场景不同，经营页面天然不可能一样，如果你公司并没有这么一套经营页面主动搭建的工具，并且业务上又高度依赖于线上经营，那么这就是你的机会
adapter
挪动端已成为支流，前端开发次要聚焦于 app、m、小程序三端，而小程序端又能够细分为微信小程序、字节小程序、百度小程序、支付宝小程序、快利用等，如果为这些端每一个都专门开发一套代码，显然会对人力产生较大的需要，如果这么多端全做了的成果是 1+ 1 等于 2，那还算能说得过去，但现实情况必定是 1 + 1 小于 2 的，如何能以最小的老本笼罩那么多渠道，就是一件很迫切的事件了
于是，多端适配的解决方案呈现了，它极大地晋升了开发效率，不仅又快又好地实现了一套代码多处运行这件事，同时还间接地为公司节约了一大笔研发费用，价值毋庸置疑
那么你能做什么呢？
相似于 Taro 这种多端适配框架，的确适配了很多货色，但适配的都是凋谢的货色，例如微信小程序、字节小程序、ReactNative 等，这些都是对外开放的开发平台，然而你公司本人开发的 app，例如抖音 app、支付宝 app，必定有本人公有的一些协定，比方唤起 app、关上页面、调起拍照性能等，这些公有协定个别是不对外开放的，如果你不仅想让一份代码运行在小程序、m 端，还想让这份代码也能在 app 端失常运行，那么适配 app 这部分的能力，显然须要公司外部员工来实现
组件库
哪怕是在前端刀工火种的时代，Bootstrap 这类前端框架就曾经大行其道，到当初前端组件化大行其道，各类前端组件库层出不穷，实质上都是为了晋升开发效率，一些通用的 UI 与逻辑拿来即用，作为开发者只须要分心业务逻辑即可
但也并不是说 iview、ant-design这些组件库就能够横行无忌了，pc后盾我的项目还好，但如果是挪动端 C 端的产品，对于组件库的抉择就须要审慎很多了，特地是那些知名度较高或者场景较为显明的产品，对于格调的要求比拟高，被宽泛应用的开源组件库并不一定能满足要求，比方，支付宝和微信显然都有本人独特的 UI 格调，开源组件库不可能专门去适配某一个产品的格调，否则就失去了通用性，而支付宝或微信这类具体的 app 也不可能为了省事就放弃本人的格调间接用开源组件库，所以打造专属于本人的组件库就成了一件很显著的事件
实际上用户量略微多点的 C 端产品，对于专属组件库都是存在需要的，所以如果你所在公司业务场景次要在挪动端，而且你发现还没有专属于公司外部的组件库，那么不要犹豫，马上放手去做，这么显著的事件你不做，早晚有人做
其余的还有很多，例如脚手架、国际化、工具函数库等，都是一些有理论需要的货色
前端如何参加业务
在绝大多数公司，个别都是由 pm 来主导产品，前端毕竟是开发人员，想要在产品层面上跟产品经理 battle，无异于是业余挑战业余，既不适合也没有胜算，但并不意味着开发就齐全无奈参加到业务中去了，pm 对于整个产品的宏观全貌必定把握得比你深，但在一些细节的局部就不肯定比一线理论开发人员分明了，而细节往往是从具体的需要中体现的
需要个别是由产品提出的，但需要往往须要开发来实现，而产品提需要的目标是为了实现这个需要，侧重于产品层面，目的性较强，开发层面的事件还须要开发来评估，那么这个 gap 人造就是开发参加业务的机会
提需要
提需要并不齐全是 pm 的特权，作为开发同样能够提需要，业务需要或者不是那么容易就能提出的，然而技术需要却是你作为开发人员的专利
作为前端，必定是要关怀本人所做前端页面的一系列的指标的，次要围绕性能、交互与格调款式这三个方面，页面加载快不快、交互是否晦涩、格调是否舒服对立，都是须要时刻关注的点，出了问题你就要去被动解决它，而不是等 pm 来找你，这是技术上的事件，该由你来负责
所以你能够光明磊落地提技术优化需要，不敢保障一个晦涩的页面会让用户忠诚度更高，但一个蹩脚的页面必定会让用户散失的（除非你是银行网站），所以技术需要外表上是技术需要，实际上也是为了业务思考
需要可大可小，小的如款式格调对立，大的则能够建设一个前端技术我的项目
例如，产品心愿通过继续的经营流动迭代来维持用户活跃度，那么他想要的就只是开发人员可能按时实现经营页面的上线，至于开发怎么去做这件事他不关怀，只有达到产品目标就行
那么作为前端开发，你意识到经营页面能够做成可配置化的状态，所以就须要你去跟 pm 进行切磋，例如这种做法是否可行、配置后盾做成什么样、须要预置哪些模板、须要预置哪些页面能力、数据存储的状态等
再进一步，你还能够持续跟产品确认，这这些经营流动未来是否可能会在多端铺开，如果是，那么你就还须要思考多端兼容的问题了
看起来，原本一个简略的经营流动，没啥难度也没啥工作量，应届生一天就搞完了，而后你作为开发参加进去，硬是把这个需要拆成了好几个大我的项目，如同是本人没事给本人找事
的确，有些人就善于_无中生有_，终日搞些看起来高大上实际上屁用没有的货色，但也别一棍子打死一群人，无中生有并不一定是贬义词，如果经营搭建后盾和多端适配的确是有需要的，那么这件事件早晚得要做，而你能提前看到这一点并且提前做好筹备，为业务的平滑过渡提供了保障，这就体现出了你工作教训的价值
砍需要
pm 提出的需要并不一定就是正当的，一个负责的技术人员对于需要该当有肯定的判断力，对于不合理的需要要坚定说不
这里的意思并不是让你去鸡蛋里挑骨头给 pm 的工作制作人为阻碍，相同的，而是给出更好的见解，独特为业务负责
比方，你当时和产品约定好了一套解决方案，在某个具体的性能上，产品发现数据不达预期，于是想要你专门为这个性能开发一个特定的逻辑以晋升数据，这件事件可能的确能够做，并且技术上也不难实现，但作为开发人员你还要为整体的技术计划负责，约定好了的计划，为了某个特定的性能增加额定的逻辑，会不会对整个技术计划造成毁坏？会不会千里之堤; 溃于蚁穴产生久远的负面影响？还有没有其余更好的解决形式？
看起来，仿佛有点推诿扯皮的意思了，但如果你的出发点的确是为我的项目思考，并且理由足够让人服气的话，谁又能说你是在推诿扯皮呢？
可能有理有据地阻止不合理的需要，将无限的人力、工夫破费在更重要的需要上，能力更好更快地推动业务
只是前端？
很多人都说后端比前端更加贴近业务，实践上仿佛是这样，但我的认识是，具体到集体的话，还是要看你本人的态度，如果后端只是日复一日地 CRUD，既不被动理解业务，也不赋能业务，再贴近业务又有什么用？同样的，前端如果只是甘心于当切图仔，哪怕每个需要 pm 都专门给你讲得清清楚楚也没用
所以还是要看集体的主观能动性，在技术之外，要被动去看更多的货色，我不是让你去一行行看后端代码，当然，你有工夫看也能够，只是没必要，业务代码没什么难看的，反而看得脑壳疼，业务由一个个需要迭代而来，那么想理解业务就从需要着手
pm 提了一个需要，你不仅要关怀前端须要切哪些图片做个什么款式应用什么组件等技术问题，还要弄明确 pm 为什么提做个需要，这个需要解决了什么问题，波及到的上下游关系等业务层面的事件
跟后端约定接口字段，不仅仅是盯着后端给你返回所需的字段就行了，还要多思考一些，例如，接口是否有可复用性、字段是否冗余、有没有必要做接口的拆分或整合、前端如何保障接口出错的状况下页面仍旧是可被用户承受的？有些可能应该是后端应该做的，但你不能保障所有人都尽职尽责，那么你就能够多关怀一些事件
当需要评审的时候，pm 更多地询问你的意见，当约定接口的时候，后端更习惯你来制订接口规定，当你关怀的事件越来越多范畴越来越大，这个时候，你还感觉前端只是切图仔吗？
如果你成了最熟悉业务的人，那么团队中其余成员遇到不了解的业务问题，第一个想到的必定是你，那么你在这个团队中就有了具备实质性存在的价值，而且是不容易被替换的那种
须要留神哪些事件？
技术是立身之本
下面说了那么多业务如许如许重要的货色，可能会引起一些人的误会，感觉既然是这样，那我连忙 all in 业务得了，反正技术仿佛也不重要
这种想法也是谬误的，你既然是一名技术人员，那么技术对你来说就是本职工作就是立身之本，想要往外延长到更多的畛域，首先必须要先把本人的根基打牢才行，若是连技术这点事件都没整明确，就嚷嚷着要搞什么业务和治理，可能最初失去的只是人心涣散
那么如何均衡这二者的关系呢？
对于前端这一行来说，我的倡议是，前两到三年，更多的精力（最起码 80% 以上吧）投入到技术下面，保障在两到三年外在前端技术层面，可能达到合格的状态
什么是合格的状态？量化一点地说，就是网上失常场景下的任意前端面试题，你有 80% 以上的把握能答出来，能够实现工作上提出来的任意前端需要，可能保障本人所写代码我的项目的稳定性和可扩展性，前端畛域新呈现的技术你都能疾速上手并且了解其原理，对于大部分人来说，这个应该不难
而后，剩下的 20% 用来关注业务，留神是关注业务，至于参不参加不太重要，因为两年工作教训之内的菜鸟，在业务上是没有多少话语权的，并且思考形式还不成熟，这个阶段更多地是察看，察看业务是如何运行的，察看其余更高级别的人是如何参加业务的，学习他们身上的长处，进而造成本人的思考观点
两到三年后，你差不多也升了职级，在团队中的位置有了少许的晋升，你谈话的重量也能引起其他人的留神了，这个时候，你再开始尝试着去参加业务，将本人在前两年学到的、总结下来的技巧和观点，真正地使用到业务中去
不要闭门造车
无论你想做什么事件，首先都要以凋谢的心态去面对，而不是打定了一个主见后就立马埋头苦干，在做之前先聆听其他人的意见，看看是否有更好的解决思路
比方，你想做一个前端谬误监控零碎，你可能从网上查了具体丰盛的对于前端谬误监控的材料，而后感觉信念满满能够开干了，而后你本人一个人起早贪黑默默干了几个月，终于弄出了一个像样的我的项目，这个时候你拿进去筹备一举成名的时候，后果你 leader 却满脸惊讶地跟你说你难道不晓得有 Sentry 这个货色吗？
或者你在网上查找前端谬误监控材料的时候，无意间发现了 Sentry，于是决定本人先上手相熟一遍，弄清楚了所有开发部署流程之后，拿进去筹备干一票大的，后果你 leader 满脸惊讶地跟你说你难道不晓得隔壁部门前段时间就曾经基于 Sentry 搞出了一套实用于咱们公司的监控零碎了吗？
所以，肯定要多跟外界进行交换，一方面是为了能从外界获取更多的信息，另外一方面则是让其他人晓得你在做什么事件(至于为什么要让其他人晓得你在做什么事件，这个各位自行领悟)
用数据谈话
作为前端，你能够提需要，也能够砍需要，甚至能够对后端指手画脚（当然，我更倡议你虚心一点），但前提是肯定要有足够的底气，而理论的数据能够赋予你这个底气
你要提一个性能优化的技术需要，须要好几天的工夫，如果你只是说前端性能不好须要几天优化一下，这显然无奈压服放心我的项目进度被延误了的 pm，然而如果你能拿出理论的数据，例如，当初网站加载须要多长时间、发动多少个 http 申请、代码体积多大、FP/FMP/TTI 都是多少、低于行业标准多少间隔、可能会对业务造成什么样的影响，而后优化后又能达到什么样的成果，有理有据地摆好数据后，pm 只有是个正常人，必定会认真考虑一下你的倡议的，即保持以理服人
良好的心态
不同于技术的纯正，业务上的事件必定跟人无关，跟人无关的事件必定就会有磨合的过程，在推动一项业务倒退的过程中，必定会遇到很多有意无意的阻力，这可能会让抱着一番善意致力做事的你感到憋屈，感觉本人一番善意不被认同，还不如每天划划水算了，这不仅是对工作不负责，更重要的是，对你本人不负责(毕竟，你必定不想 35 岁就就业了吧)
业务根本是都由团队推动，简直不存在集体单打独斗的可能，团队中的每个人都有本人的短处，每个人的短处汇聚到一起，才成就了团队的战斗力，可能顺利地推动团队交融与发力，可能比你攻克了一个技术我的项目还要重要的多
不要总感觉共事 sx，你们既然同属于一个公司甚至部门，就阐明你们的能力是差不了多少的，如果你感觉身边人都是 sx，那么你大概率也是，所以当你斗志昂扬地要实现一个业务指标却遇到了阻力的时候，先别急着骂共事 sx，平心静气地讲事实摆情理，切实不行就走个流程，大家都是打工的，谁没事去成心针对你？
你只是在工作而已，犯不上因为工作上的事件让本人不开心，有问题就解决问题，做好你认为该做的事件就行了，要置信领导能坐在那个地位上成为领导，大概率不是傻子(如果真的是，倡议你为了前途着想还是连忙换一家公司吧)，真正实干的人，必定更容易失去机会与赏识
小结
原本只是想写怎么深刻业务的，但前面感觉写着写着更像是职业倒退领导了，就这样吧
以上只是我目前集体的一些见解，毕竟教训无限，所以可能有些观点还不是太成熟，欢送更多的探讨
最初
听过很多情理却仍旧过不好这毕生，同样的，看过很多心灵鸡汤，却仍旧不晓得如何挣脱瓶颈，这个时候，我倡议你换一个环境
不要埋头苦干，借助于外力的作用，会更加轻松，当身处于一个暮气沉沉的环境中时，你哪怕是跟着团队的惯性也能继续往上走，巧的是，字节跳动就是这么一家充斥干劲的公司（手动狗头）
字节跳动商业化前端团队继续招人！
不低于 20 个 HC，这里有两篇我小师妹写的对于团队状况的文章：我帮你们问了问字节跳动的面试官、停，我说一个数，海量 HC，3 分钟！，能够找她内推，也能够找我，简历发我邮箱 kother@foxmail.com，可帮忙给看简历，所有投给我内推的简历，保障全程有回复（我会鸽你吗？咕咕）
作者：清夜
链接：https://juejin.im/post/687697…
起源：掘金
著作权归作者所有。商业转载请分割作者取得受权，非商业转载请注明出处。