周末和某东的一个同事小聚了一下，开始小酌几杯，然后从诗词歌赋谈到人生哲学再到如何实现财富自由，时间到了进入了微醺的状态，也不由自主的开始面对现实。话锋一转聊起了当下又爱又恨工作，之后疯狂的吐槽自己做的不开心，不想做B端前端了，太TM无聊了，每天的工作内容基本都差不多，觉得自己就是个做需求的工具人，特别羡慕那些C端的前端，觉得C端更好玩更刺激，距用户更近。

而我的工作方向主要在C端，心想C端有那么香吗？我估计当你做过C端后，你才知道B端是多么爽。

这个问题可以延伸下，如果你在选择一份工作时，你是选择C端方向还是B端呢？

说实话，我个人觉得B端更好，如果你想提升能力（提升知识面），接触大前端（看你的取舍），搞性能优化（永远做不完）那就选择C端。

用户群

C端距离用户更近，用户群更大，B端用户群主要是给公司员工如产品、运营、渠道或者商家使用。

性能

C端注重用户体验，所以性能优化会持续的进行，因为没有最好，只有更好。

B端更注重稳定性，性能上一般都不需要进行特殊优化，基于框架开发的性能都不会太差，一般都能接受。

交互复杂度

C端交互形式简单，表单操作几乎没有，主要是查询和渲染为主，对动画要求也较高。

B端交互复杂，表单操作那是家常便饭，主要是对数据进行增删改查。

数据分析

C端数据统计复杂，需要上报各种埋点上报，还有一些模块需要精准曝光。

B端数据统计基本可以忽略，统计这个意义不大。

知识面

C端更容易接触到大前端，因为C端渠道众多，所以涉及到的技术栈也很多，小程序、app、flutter、rn，但有个弊端就是web技术会明显减少，接触客户端的时间会更多，时间长了感觉自己都要脱离web开发了，因为你接触不到浏览器。

提效

C端提效方面主要是进行跨端复用，一套代码多端跑，发版上要依赖各种动态化方案，但鱼和熊掌不可兼得，提效和性能是永远也无法逃避的问题。不过这里我个人觉得在跨端和提效上小程序是最佳选手，虽然社区生态差了点，但看在提效的份上，我忍了。

B端提效主要是组件库，低代码，使用搭建工具来解决某一个特定场景下的问题，来提高开发效率。

运维压力

C端前端开发更胆小，犹如惊弓之鸟，每天都处于担心出问题和出问题的路上，更别说上线发版了，出小问题还好，如果是核心连路上的问题，会导致单量降低，那就要定级了，然后写写复盘。不过这里也有很多可以做的事儿，比如：如何提搞稳定性，就要做监控告警，有监控告警了就要减少误报，提高告警准确率，还有如何更快的定位问题，解决问题，处理问题时间短了，才能减少线上损失，这里我想到了阿里的三板斧，可回滚，可灰度，可监控。

那B端前端相对来说就会好很多，运行环境主要是浏览器，发版也方便，回滚也方便，出了问题影响也不大，因为他的影响范围是可控的，因为再出问题，不会影响用户下单啊。

个人成长

C端在技术栈上更丰富，你会接触到native、小程序、RN、flutter，跨端等等等等。

的确很丰富，可以让你学到很多，但凡事都有两面性，接触的多，并不代表你用的深，可能都是浅尝辄止。不过知识面是绝对有提升。

B端比较单一，可能会一直用vue或者react，宿主也只有浏览器。

虽然如此单一看似不太好，但是如果你一直用react开发了几年，不敢说精通，但是各种场景你都经历了，这个经验页是非常宝贵的。

最后

你让我选AB，我是成年人，我都不选，我选C，那有C吗？还真有。

写到这里忽然觉得营销方向好像也不错，有H5和小程序，还有B端系统，提效上可以做低代码搭建，组件库，性能优化也都需要搞， 业务产物大多运行在C端，也算兼顾C端和B端了，还能学习各种促活拉新引流的营销手段，说不准日后还成了营销专家。

欢迎自荐投稿到《前端技术江湖》，如果你觉得这篇内容对你挺有启发，记得点个 「在看」哦