作为前端，我对业务的⼀点理解
技术⾄上？
三年前我毕业进⼊第⼀家公司，个⼈很⽔的技术能⼒让我经常在实际的开发⼯作中捉襟见肘，于是就想着⼀定要尽快提升⾃⼰的技术⽔平，每天都在公司待到很晚，除了做需求就是⾃我学习，在这种情况下，我⼏乎所有能坐在电脑前的时间都⽤在了技术上，这就造成了⼀种后果，那就是我只关⼼技术⽅⾯的东西，其他的我⼀概不管，并且越来越严重
评审需求的时候，我不关⼼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，那么你会这些也没多⼤⽤，也没⼈会关⼼
如果你公司真的就⽤这些技术了呢？不好意思，这些⼜不是什么很难的东西，并不存在技术上的循序渐进，给⼀个应届⽣⼀段时间，他也能学会，⼀般情况下，⼀个部门或者团队也不可能⽤很多种技术栈，技术⼴度到达⼀定程度之后，再继续往上增加的意义只会越来越⼩
⼯作经验？
是，也不是
如果你⼯作三年，只是按部就班地搬了三年砖，那么你可能只是⼀年的经验⼜被你重复了两年⽽已
真正好的⼯作经验应当是持续学习与进步的，不仅限于技术上的进步，如何写好易于维护的代码、如何⽤技术能⼒保障业务的稳定性、如何引领新⼈快速融⼊团队，都是不可或缺的东西，想要获得这些能⼒，需要时间，但更需要你的主动探索与实践，⽽这些是⽆法速成的东西，也是你作为⼀个技术⽼鸟，能跟应届⽣真正拉开差距的地⽅
⽽⽆论是技术⽔平、技术⼴度、⼯作经验，它们之所以有价值，归根结底，还是因为它们都有服务业务的能⼒，所以⼀切都是围绕着业务展开的，既然⽆法避免，那么⾃然是越早学会游戏规则越好
什么是业务
在前三年，经常有资历更⾼的同事跟我提起业务这个词，听得多了，我有时候也想去了解它，但总是发现这个东西太虚⽆缥缈了，编程语⾔的语法、关键字、设计模式、算法我都可以实实在在地看到并运⽤，但业务到底是什么？我怎么学？我⼜该怎么去关注业务？
总之很苦恼，⽼是有⼈跟我说业务，但我却⽆从下⼿，硬着头⽪去模仿，最终也只是学了个⽪⽑，于是逐渐放弃
⽬前在第⼆家公司⼊职的团队，相⽐于之前来说，业务压⼒⼤很多，⼏乎没法再像之前那样优哉游哉地搞⾃⼰的技术研究，然⽽在这种环境下，反⽽加速提升了我对于业务的理解，也明⽩了为什么之前那么多⼈跟我说业务很重要，但没有⼀个⼈能教会我到底什么是业务，因为这个东西真的很难说清楚，或者换句话说，其实每天都有⼈跟你说什么是业务，但因为你⾃⼰本⾝⽆法领悟，所以你觉得他们什么都没说
在绝⼤部分情况下，技术都是要为业务提供服务的，这句话蕴含着两层意思
第⼀，技术的唯⼀⽬的就是⽀撑业务
第⼆，业务并不仅由技术⽀撑，还包含了其他很多⽅⾯
业务是⼀个商业公司的命脉所在，⽽技术只是⽀撑业务的关键之⼀，所以业务真的很重要
那么，什么是业务其实也就很好理解了，你的技术所服务的就是业务，⽽你能够让业务蓬勃发展的⼀切正向能⼒（包括但不仅限于技术能⼒），都是业务能⼒
前端如何赋能业务
肯定有⼈会吐槽我说了半天还是啥都没说，没错，确实是这样，对始终不明⽩业务是什么的⼈来说，别⼈说得再多也很难理解，对于已经理解的⼈来说，业务就是业务，根本没什么可说的，可能真的就需要你⾃⼰领悟才⾏，或许某⼀天你⾃⼰就突然明⽩过来了
很难说清楚业务这个词到底是什么，但⼯作中处处是业务
前端如何赋能业务的话题⽐较⼤，但具体的例⼦却很多
运营页⾯⾃动搭建
运营⼿段对于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更多地询问你的意见，当约定接⼝的时候，后端更习惯你来制定接⼝规则，当你关⼼的事情越来越多范围越来越⼤，这个时候，你还觉得前端只是切图仔吗？
如果你成了最熟悉业务的⼈，那么团队中其他成员遇到不理解的业务问题，第⼀个想到的肯定是你，那么你在这个团队中就有了具有实质性存在的价值，⽽且是不容易被替换的那种
需要注意哪些事情？
不要闭门造车
⽆论你想做什么事情，⾸先都要以开放的⼼态去⾯对，⽽不是打定了⼀个主意后就⽴马埋头苦⼲，在做之前先倾听其他⼈的意见，看看是否有更好的解决思路
⽐如，你想做⼀个前端错误监控系统，你可能从⽹上查了详细丰富的关于前端错误监控的资料，然后觉得信⼼满满可以开⼲了，然后你⾃⼰⼀个⼈起早贪⿊默默⼲了⼏个⽉，终于弄出了⼀个像样的项⽬，这个时候你拿出来准备⼀鸣惊⼈的时候，结果你leader却满脸诧异地跟你说你难道不知道有Sentry这个东西吗？
或者你在⽹上查前端错误监控资料的时候，⽆意间发现了Sentry，于是决定⾃⼰先上⼿熟悉⼀遍，弄清楚了所有开发部署流程之后，拿出来准备⼲⼀票⼤的，结果你leader满脸诧异地跟你说你难道不知道隔壁部门前段时间就已经基于Sentry搞出了⼀套适⽤于咱们公司的监控系统了吗？
所以，⼀定要多跟外界进⾏交流，⼀⽅⾯是为了能从外界获取更多的信息，另外⼀⽅⾯则是让其他⼈知道你在做什么事情(⾄于为什么要让其他⼈知道你在做什么事情，这个各位⾃⾏领悟)
⽤数据说话前端ui框架是什么意思
作为前端，你可以提需求，也可以砍需求，甚⾄可以对后端指⼿画脚（当然，我更建议你谦虚⼀点），但前提是⼀定要有⾜够的底⽓，⽽实际的数据可以赋予你这个底⽓
你要提⼀个性能优化的技术需求，需要好⼏天的时间，如果你只是说前端性能不好需要⼏天优化⼀下，这显然⽆法说服担⼼项⽬进度被延误了的pm，但是如果你能拿出实际的数据，例如，现在⽹站加载需要多长时间、发起多少个http请求、代码体积多⼤、FP/FMP/TTI都是多
少、低于⾏业标准多少距离、可能会对业务造成什么样的影响，然后优化后⼜能达到什么样的效果，有理有据地摆好数据后，pm只要是个正常⼈，肯定会认真考虑⼀下你的建议的，即坚持以理服⼈
良好的⼼态
不同于技术的纯粹，业务上的事情肯定跟⼈有关，跟⼈有关的事情肯定就会有磨合的过程，在推进⼀项业务发展的过程中，肯定会遇到很多有意⽆意的阻⼒，这可能会让抱着⼀番好⼼努⼒做事的你感到憋屈，觉得⾃⼰⼀番好⼼不被认同，还不如每天划划⽔算了，这不仅是对⼯作不负责，更重要的是，对你⾃⼰不负责(毕竟，你肯定不想35岁就失业了吧)
业务基本是都由团队推进，⼏乎不存在个⼈单打独⽃的可能，团队中的每个⼈都有⾃⼰的长处，每个⼈的长处汇聚到⼀起，才成就了团队的战⽃⼒，能够顺利地推动团队融合与发⼒，可能⽐你攻克了⼀个技术项⽬还要重要的多
不要总觉得同事sx，你们既然同属于⼀个公司甚⾄部门，就说明你们的能⼒是差不了多少的，如果你觉得⾝边⼈都是sx，那么你⼤概率也是，所以当你⽃志昂扬地要完成⼀个业务⽬标却遇到了阻⼒的时候，先别急着骂同事sx，⼼平⽓和地讲事实摆道理，实在不⾏就⾛个流程，⼤家都是打⼯的，谁没事去故意针对你？
你只是在⼯作⽽已，犯不上因为⼯作上的事情让⾃⼰不开⼼，有问题就解决问题，做好你认为该做的事情就⾏了，要相信领导能坐在那个位置上成为领导，⼤概率不是傻⼦(如果真的是，建议你为了前途着想还是赶紧换⼀家公司吧)，真正实⼲的⼈，肯定更容易得到机会与赏识
⼩结
本来只是想写怎么深⼊业务的，但后⾯感觉写着写着更像是职业发展指导了，就这样吧
以上只是我⽬前个⼈的⼀些见解，毕竟经验有限，所以可能有些观点还不是太成熟，欢迎更多的讨论
最后
听过很多道理却依旧过不好这⼀⽣，同样的，看过很多⼼灵鸡汤，却依旧不知道如何挣脱瓶颈，这个时候，我建议你换⼀个环境
不要埋头苦⼲，借助于外⼒的作⽤，会更加轻松，当⾝处于⼀个朝⽓蓬勃的环境中时，你哪怕是跟着团队的惯性也能持续往上⾛，巧的是，字节跳动就是这么⼀家充满⼲劲的公司

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。