@Nosub C# 客户端生态差？？？？？？？？？你这又是从哪儿听到的逆天言论？ 还 Java ？？？？？？大哥你认真的？？？？如果说 C# 做客户端生态还叫 "差" 的话，那 Java 那就可以视为没有了啊！怎么还有推荐用 Java 做客户端的？你怎么想的？

FFMpeg 、OpenCV 、SDL 、WebRTC 这些 nuget 上都有相关库啊？？？你到底用过没啊？我前段时间给自己家用树莓派做门禁的时候就用到了 FFMpeg 跟 OpenCV 。如果这些 C# 都不支持那我怎么做的？？

Electron 是首选。
别关心什么内存占用的问题。那不是你该关心的问题。除非涉及到 C++ 交互，否则 Electron 永远是不二之选。界面美观开发简单。没什么比 Electron 更合适的。

然后其次是 Avalonia 。性能强悍内存占用低，可 AOT 所以也不需要什么 .NET 环境。打包好了到处都能用。尤其涉及到界面复杂或者带动效/3D/图表的情况下，Avalonia 基本上可以说是唯一选择。

最后是 QT 。老牌 GUI 开发框架了。性能极其强悍，但是绑定 C++。对 C++ 熟悉的可以考虑。

没有可能.

只要你们公司存在人员流动, 功能更迭, 代码的腐化就是不可避免的. 任何的规范和制度都只不过是延缓其发生而已, 不可能避免. 很多很多的功能其实开发的时候, 功能描述里说的可能只是一个很简单的需求, 但是实际上开发的时候, 隐藏在里面的逻辑却可能是相当复杂的. 而这种复杂并不是一句两句话能说得清的. 而一旦编写这种复杂业务逻辑代码的人离职, 这段代码很可能就会变得难以维护. 就算是留下交接文档, 这种编写于几年前的复杂业务逻辑代码, 当事人也不一定会记得当时的逻辑细节. 更何况很多情况下人员并不是主动离职而是被辞退/优化掉的, 这种更是连交接的过程都不会有. 这种过程多来几次, 你的代码就基本没法儿看了.

@lujiaxing 效率。打错了

@jinxjhin 是的，直接位运算就可以了。不需要 IN. 单字段运算的线路永远是 IN 所不能比的，尤其 IN 的数量大时候

不是, CEF 是能独立存在的么? 它总有个宿主吧? 不是 WinForms 就是 WPF 啊!! 你要单独搞一个界面显示 WPF 的图表那你就单独建窗体呀! 跟 CEF 有什么关系呢?? 你们是用 CEFSharp 还是 chromiumfx ??

但无论如何这些都不是单独存在的, 都是要有宿主的...

你这不是 "+" "-" "=", 是 "从 '+' 到 '='"....

'1'.match(/[+\-=]/) 才对

@sadfQED2 那如果确实是已经 100% 完善了, BUG 清零了, 客户跟产品方面也暂时没有提到过什么新的需求, 那你们又要发什么

@awesomePower 人员变更不是问题呀.
部门权限查询的时候是按人所属部门来的. 他就算是换了个部门, 也是按新的部门的权限查. 他的权限在人员组织架构变更的瞬间就已经跟着改了.
至于人的权限, 人员离职之后人员被标记删除, 这时候他的数据权限归零也好, 留在那也好, 都无所谓了. 反正人都不在了. 新增人员只需要将对应权限增加一个 bit 即可. 嫌麻烦你可以先固定生成一个 100W bit 的二进制数据, 全部填零. 这样就不需要每次都延长数据权限字段数据长度了

这跟 ntdll.dll 没有一分钱关系.
你去 mysql 的 log 目录看下 error 日志才知道怎么回事

@lujiaxing 是 1000. 不是 10000000....000. 勘误

这个我以前倒是做过. 就是数据权限嘛.
当时的需求是:
1. 自己部门的一线员工可以看自己部门的数据.
2. 上级部门领导可以看本部门以及下属部门的数据. 上级部门的一线员工不可以查看下属部门的数据.
3. 部门可以临时抽调人员, 临时抽调人员享有跟借调部门一样的数据权限. 同时被抽调人员仍享有自己原属部门的数据权限.

我当时是这样设计的:
由于我们的用户表与部门表都存在自增 ID, 那么数据权限就是在每条数据后面增加两个字段: 部门权限, 个人权限.
全都是 blob 类型, 大端.
里面按 bit 存储权限. 比如 ID 为 1 的用户可以看, 那么个人权限里的权限二进制值就是 "10000000....000" 即 0x08.
1 2 3 三个用户可以看, 二进制存储就是 1110. 即 0x0E. 以此类推. 按部门权限查询的时候只需要查到这个用户所属部门, 是否为部门领导即可. 如果是部门领导, 则将本部门与下属部门的数据权限做 OR 运算, 就能得到他能看得到的数据了.

几个亿而已...

PostgreSQL 了解一下?

星穹铁道适合你.