一次 github 跟开源大佬的抬杠经历

先叠个盾：感谢所有开源作者的贡献

不是前端，写个小工具，需要有个简单的界面，于是找了一个比较知名的开源前端 UI 库，非常好上手

几十分钟就写完了，非常不错完全就按照 sample 拷的代码就行了因为也只是需要一些基础的功能，显示个 alert ，做个 input 采集用户数据之类

调试时，发现了一个问题，UI 组件之间的排列逻辑有点小问题，于是!important 一把梭完成任务收工

闲下来了，觉得这问题肯定不是我一个人遇到的，就去了 github 提了个 issue 标签 bug

就像我前面说的，我也不是前端，基本停留在知道 dom 是啥会 getElementById 和理解简单 js 语法的程度

问题所在呢，就是这个 UI 库提供了一个组件，就是整个屏幕都变成半透明灰色没法点，然后中间弹一个类似桌面程序 modal 窗口的的框弹出的是白色的框，产生反差，里面可以自由发挥 html 代码的组件 不知道这玩意你们一般叫啥

这个组件显示是正常的，我完全 copy 的手册的代码，只是把中间的文字替换成了我要显示的文字

然后无意发现，这个组件下面的基本布局组件里有个色块，不会被变灰遮挡，也不会被弹出的 modal 窗口遮挡，modal 窗口正中间有个超级鲜艳的色块

我对 html 还是有点概念的，这应该是下面那个组件里有一部分颜色功能用了 relative/absolute 定位（这玩意不存在用 fixed 定位吧）给了个 z-index 1 导致的问题相当于类似 floating 的状态

他 z-index 给 1 是因为他想让这个东西显示在他那个组件内部的基准层上面 1 层

而这个白色的框是 display:block 的普通定位就到下面去了

这里我最开始犯了个错误因为这个 modal 状态 F12 不好定位而 html 是通过前端框架渲染的代码里写的是模板所以我漏掉了直接看那个白色框的 block 的状态 position 是默认值刚开始以为这个组件整体不是 floating 的状态

提完了 issue 很快维护的大佬就来解答了

他纠正了我的错误分析告诉我这个组件都是非默认 position 的

然后我又回去仔细找了下，确实，那个背景整体变灰是个 fixed 的 width height 都是 100%的 div 且 z-index 是 1

两个 z-index 都是 1 结果就是按定义顺序了问题发现

维护的大佬纠正的我的想法时，另外说到： “这是个 z-index 合不合理的问题”

我认为这不合理，我就反问了一句，那你认为这种 modal 功能而论，给 1 的 z-index 到底合不合理？说这话时候，我认为这不合理。我认为这种组件默认应该有一个较高的 z-index 。没必要最高给个 2000 但是高于一般组件让这个东西确实能遮住大部分组件，应该是正常人类应该有的思维吧？

到这里，我这个职业杠精八代高低杠转世都没想杠什么，您说了，我就一提，委婉的表示了一下我认为这个不太合理，咱是不是要在远期版本改进一下这个默认值改个 3 或者 5 之类这就完事了

然后就得到了一个公式化的答复

“它们的层级是一样的，所以最终它们展示上的层级和在文档流的顺序也有关系。修改默认的 z-index 值属于 breaking change 。不过提供了 z-index 的 prop 和 css 变量，你可以根据项目的实际情况进行配置。”

说实话，这玩意我已经改完了，也没用他的方法，因为文档里压根就没写过这玩意要怎么改，变量在哪也没看到，也没有说明。我不觉得一个公开的知名的广泛传播的开源组件，我不过分的基础用法使用它还得去看他源码怎么写的才能正常用

然后我就吐槽了一句，贵司果然大厂风范。然后我就主动 close 了这个 issue 。毕竟大周末的，不是带薪抬杠，跟大佬在 github 杠不划算……

为啥大厂风范呢？因为这个开源代码在某个大厂的组织下，而不是在个人作者名下。项目简介明确写道是该厂开源产品，且用了该厂商标。

都 closed 了的，该大佬又跑来跟我一顿解释。

可是我就想知道，大佬认为这个到底合不合理，我就杠了一下我只是想知道你认为到底合不合理

然后又换来了长篇大论的解释……

可是我只是想知道，到底大佬们怎么想的，这种设计到底合不合理。你要觉得合理，你就告诉我合理，以后我也多学习学习怎么设计这种合理。

我就又补充了一句，我只是想知道到底合不合理，能不能用一个字或者两个字告诉我到底合理不合理。我说大厂风范，就是指的这种从不正面面对问题，顾左右耳言他的行为

然后，我就又收获了更长的一篇长篇大论……

这次还用 markdown 给我列了 1 2 3 4

其中第四条是

“默认的值无论是什么都有可能在某个场景下是不合理的。”

我就想知道，现在程序员的群体里，都已经这样了么？话不能直接说，沟通不能简洁有效什么都得长篇大论，生怕触动了原始写这段代码的巨佬的权威

你觉得合理，你就明确的告诉我合理，我也接受就完事了

xiaoranj

172 天前

太长不看系列

- **一次 github 跟开源大佬的抬杠经历**：这是一个 V2EX 的社区帖子，作者 realpg 分享了他在使用一个大厂开源的前端 UI 库时，发现了一个 z-index 的问题，并在 github 上提了一个 issue 。他描述了他和维护者的对话过程，以及他对维护者的不满和吐槽。
- **z-index 的问题**：作者发现了一个 UI 库提供的一个 modal 组件（类似桌面程序的弹出窗口）的问题，就是这个组件下面的基本布局组件里有个色块，不会被变灰遮挡，也不会被弹出的 modal 窗口遮挡，造成视觉上的干扰。作者认为这是因为这个色块的 z-index 设置为 1 ，而 modal 组件的 z-index 也是 1 ，导致了层级冲突。作者认为这个设计是不合理的，modal 组件应该有一个较高的 z-index ，以确保能遮住大部分组件。¹[1]
- **维护者的回复**：维护者很快回复了作者的 issue ，纠正了作者的一些错误分析，解释了这个问题的原因和解决方法。维护者说这个问题是因为 modal 组件和色块组件的层级是一样的，所以最终的展示顺序和文档流的顺序有关。维护者说修改默认的 z-index 值属于 breaking change ，不过提供了 z-index 的 prop 和 css 变量，可以根据项目的实际情况进行配置。²[2]³[3]
- **作者的反应**：作者对维护者的回复不满意，觉得维护者没有正面回答他的问题，也没有承认这个设计的不合理性。作者还觉得维护者的解决方法不够明确和方便，需要去看源码才能知道怎么改。作者就阴阳怪气地说了一句“那没问题了贵司果然大厂风范领教了”，并主动关闭了这个 issue 。作者说他只是想知道维护者到底认为这个设计合不合理，而不是想听一堆长篇大论的解释。⁴[4]作者说这就是大厂风范，就是指的这种从不正面面对问题，顾左右而言他的行为。⁵[5]
- **其他人的评论**：这个帖子引起了一些其他人的评论，有的人认同作者的观点，有的人觉得作者是在杠精，有的人给出了一些开源项目礼节的建议。