对于研发工作者而言，如果有人问你：在日常研发工作中，最让你痛苦的事情是什么？想必你会不假思索的回答：互撕。这个词对任何一个从事过互联网研发的人都很清楚，其他行业也不算是陌生。

这个词应该算是一个中性词，不能用褒贬来形容。用这个词来形容人与人在工作中相处的情况，确实也是有一些粗暴。与之相对应的也会有很多礼貌用词，比如：争论、探讨、表达、理解、包容等等，这些词都是类似的场景表达。但是，这些词在研发工作中非正式场合却没存活下来，“互撕”这个词不仅“活”了下来，还成了职场的一种标准。

一个物种能存活下来一定有它的原因。词语、语言也是一样。“互撕”这个词从互联网，确切的讲在研发行业中更是有让其发展的土壤。先看看这个词涉及到的对象。大体会有：研发、产品、测试、业务、运营等等，每一个角色还会有更加细致的划分，研发又会分为：后端研发、前端研发。后端研发继续分：业务后端研发、大数据后端研发、架构师等等；前端研发又会分为：Web前端、Andriod、iOS、鸿蒙等等。 

至于如何能有这么多分类就不去讨论了。重点看看互撕是怎么在研发场景中发挥作用的。介绍这个之前始终离不开对需求交付场景的阐述，尤其

在这个“互撕”参与场景中发挥着什么样的作用。

有这样一个还是关于商旅的需求。需要将某一页面的查询操作开放给客户，这样客户也就能查询到相关的数据。这样也就会引出权限情况，就是权限控制。

场景很简单：A公司的用户A，要查询相关商旅订单数据。那么用户A只能看到A公司的数据，这就需要在页面要控制好查询条件，后台做相关查询条件的操作与数据鉴权。之前介绍商旅业务系统时也说起过，公司逻辑关系是重要的商旅数据查询条件。

每个商旅业务页面几乎都会涵盖： 使用公司作为查询条件来查询结果集。查询条件又区分：一级公司、二级公司和三级公司。这时候问题就来了，产品的需求是：不输入公司查询条件、输入一级公司、或一级二级公司、或一级二级三级公司，都能查询出对应的结果集。就是应该用可变的符合条件查询出准确的结果。

所谓的符合要求，就是权限控制。之前文章也提到过，在权限平台还没有上线、还要满足用户需求时，采用了折中的方式：临时表权限。后面待权限平台上线后通过总开关和账号开关的方式完成临时表权限和权限平台的切换。

“互撕”的问题就出在这上面。首先说接入临时表权限，当时作为权限的折中方案，权限平台在未能提供控制鉴权的情况下，提供了一个接口方法，依赖于临时表返回一级、二级、三级公司的信息

串，将这个交给前端，前端的下拉框选择基本就控制了数据权限。

不同的查询场景就会有不同的查询条件，前端为了能更清晰的符合产品需求做了如下处理。约定了一个查询字段

，通过这一个字段解决了全部场景的查询问题。

会传递临时表全部三级公司ID；

会传递该一级公司对应的三级公司ID；

当查询条件选择一级公司、二级公司，

会传递该二级公司对应的三级公司ID；

当查询条件选择一级公司、二级公司、三级公司，

这样处理也算是比较合理的方案。毕竟已经有接口将下拉框公司联动信息交给了前端，前端做了联动过滤查询，虽然有时候是真实的联动、有时候并不是真实的联动。对于前端工作量也是很顺其自然的过程；后端直接拿权限就行了，到权限平台上线的鉴权操作也都是很容易的逻辑操作。

最初是几个页面，为了满足于产品和业务的需求，对系统继续下去，发展到了十几个页面都是通过这种方式做前、后端交互。权限平台完全上线后，这十多个页面加入权限鉴权也是按着

有一句俗语：少数服从多数。从这句话又衍生出了另一句：多数人坚持的东西不一定都是对的。通过这两句话可以讨论下这种情况处理前后端交互是不是合理。

对于研发过程我们讨论合理不合理必须有对应的标准做衡量。对于这些查询场景大体从这些标准来评估，包括：数据准确性、研发效率、运行性能、系统安全、代码继承于发展这些方面分别讨论一下。

通过这种方式准确性是符合要求的。前端拿到了一个权限的范围，公司下拉框条件不会脱离这一范围。这个范围传到后端，在

语句中完全能实现查询的准确性；

这一点对于前后端都是能有所体现。前端即使不做三级公司的获取，一样要做一二三级公司的联动，只是将联动的操作由人工手动换成代码运行方式实现。对于后端呢？抛开权限平台的鉴权操作，后端获取到

串后放到缓存，无论怎么弄变换公司下拉框的查询条件，都是在操作缓存数据，这期间没有任何的前后端交互、数据库交互，明显提升了查询效率。后端也不需要反复的通过一级拿三级、二级拿三级的繁琐数据库操作，查询性能更是大大提升；

无论前端怎么传递数据，都会存在前后端加解密操作，而且是一堆id数据的操作。无论

请求怎么变化，再加上后期的权限平台鉴权使系统安全性牢不可破；

无论是前端还是后端，有了这一个模版操作，完全能做到多个页面，或者说是更多页面的集成使用。也利于后期系统的业务需求的变更，比如：产品提出必须选择三级公司，前后端仅仅就是个空值判断，不用考虑公司下拉框联动和其他的联调工作；

综合看这种解决方案，不敢说是无与伦比，但是的确满足了一个工程类系统需要具备的条件。

问题是发生在一个账单页面和报销页面的交互，也算是一个特殊场景。就是在账单页跳转到报销页面后，需要将该账单的报销数据全部查询出来。按理说是非常简单的一个操作，对于任何一个前端而言都是很easy的事情吧。

在这个需求维护过程中，前端更换了人员，该人员不清楚前后端交互都是在依赖于

，跳转的时候需要重新获取对应的三级公司集合

。当然也有个前提，对于账单已经是按三级公司做好的数据统计，即使抛开权限也是非常容易的事情。

传递错误，导致将全部权限的数据查询出来，忽略掉了查询条件的内容。当时针对这个问题，业务方和产品方都认为不是大问题，所以也并没有强烈要求赶紧修复，而且业务方还说：“由于当前这种权限还是在业务维护人员手中，所以不影响用户，可以稍后跟版本修复即可”。

看来彼此都没有将这个问题定位成一个事不可解的问题。

可是互撕的场景出现了。这位前端看到了

的使用情况，提出了坚决的反对意见。前端把对应的后端全部拉到会里，然后开门见山的说：“这种设计不合理，之前前端只传递对应的参数，从来不做过滤，现在竟让让前端来做

，这就是不合理的”、“其他的平台都不是这样做的，都只是传递了一级、二级、三级公司，从来都没有过过滤、合并的场景”、“你们后端既然重新上线权限平台，就应该意识到这样操作的不合理，就应该重新架构”、“

的问题我已经找到了，我是不会改的，因为不合理”、“问题实在说不清楚，那就上升吧，现在大家谁都不许走，我现在就去找领导，现在必须讨论清楚”......。

标题说了互撕，其实大部分的时间都是前端在发言。这时候后端还是对前端的话语提出了一些反驳，其实也没什么好反驳的，也就是将那几点作为了说明：准确性、研发效率、运行性能、系统安全、代码继承与发展。

然而这位前端好像真的没有听懂、甚至都没有听这几个词是什么，不断的互撕着一句话：“这个方案不合理，前端从来都没这样做过”。会议没办法进行，前端找的领导也始终没有进会，没办法让前端先找领导沟通清楚，强行结束了无意义的互撕。

事情发展到这一过程，继续争吵下去、陪着前端互撕已经没有意义。不如将当前问题、已经具备的代码逻辑和数据资源交给

是否能给出较合理的解决方案，能不能对互撕有帮助。

先要看看问题都在哪些商旅应用中。前端已经确定按不是自己的问题去改了，所以要从两个方面出发来处理。第一：权限平台在鉴权时能返回对应的公司关系树；第二：查询应用可以根据鉴权公司树来组装查询条件。

在鉴权时返回公司树信息，在应用中根据请求来组合查询条件，这里既包括了选择公司查询条件、不选公司查询条件，还包括了全部权限

还是从技术实现方面给出了本次“互撕”的解决方案。但还是不能做到根据合理性和当前实际情况来与前端互撕。这种折中也许是比较好的处理方法了吧。一个问题不断的重复讨论、周而复始的互撕，没有任何意义。能做一些“妥协”，将事情办好不枉是一段好的工作态度，即使不会被领导发现，但是也能让自己良心得到安慰。毕竟在解决问题时还是直面了问题，不断互撕的人还是在逃避着。

问题的解决肯定是后端让步了。能看出这位前端是非常的强势，而且某些领导对这位前端也是“关爱有加”。但是，系统十几个页面已经使用了这种方式，怎么可能一下全部做调整。这样不仅涉及到前后端，还包括：业务、产品、测试等等，还要排上线的期限。

为了更好的权衡彼此，双方商定暂时只改这一个页面。可笑的是，即使后端做一级、二级、三级公司的权限过滤和公司条件联动，前端也要修改公司下拉框的查询与联动条件。

这个问题算是得到了解决，当然无论怎么互撕，这一场景和问题都没有完全对与错的区分，更不应该把个人情绪代入其中。工作中如果说碰到这样、那样的执拗的人，其实也无需过多的解释交流，因为不应该跟傻子过多的理论。

曾经有这么个关于刘墉的故事。有两个人找刘墉评理说：《出师表》是不是诸葛亮写的。刘墉正要回答，另个人却说：《出师表》怎么能是诸葛亮写的呢，明明是孔明啊。第一个人紧接着就说：孔明就是诸葛亮啊。那个人一直在反驳：不对，就是孔明写的，孔明是孔明、诸葛亮是诸葛亮。就这样无休止的争吵。刘墉笑呵呵的打断了他们，和那个人说：你说的对，《出师表》是孔明写的，不是诸葛亮。那个人兴高采烈的走了，第一个人很诧异的望着刘墉。刘墉赶紧又说：为了一个孔明和诸葛亮都不分的人，你干吗不让他糊涂一辈子呢。听到这里这个人也明白了，笑呵呵的给刘墉鞠了个躬，走了。

一个传参问题，为什么演变成前后端互撕？AI给出了另一条路

职业发展

后端

前端

研发场景中"互撕"是高效协作的顽疾。本文通过商旅系统权限控制案例，剖析前端与后端因公司数据查询逻辑分歧引发的技术争议。重点探讨了corpIds参数传递方案、临时表权限向平台迁移的优劣，以及AI在解决此类冲突中的局限性。最终以技术妥协换取项目推进，揭示了研发工作中沟通与决策的复杂权衡。

数据库

大数据

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

一个传参问题，为什么演变成前后端互撕？AI给出了另一条路

一个传参问题，为什么演变成前后端互撕？AI给出了另一条路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐