2 楼 @newaccount 讲的很对，相信我，一旦定制化以后，你不会有机会 merge 回来了，不同客户的需求下，分支模式并不适合。
建议把基础版本作为一个 git template repo ，需要定开的话，直接 clone 出一个新的 repo 独自演化吧。

早同步了（可能我也很激进），在 nextjs 15.0.3 + react 19 rc 上都摸了好一阵子，总算 react 发布 19 了，很多活跃的库都会及时跟上的。

@zbowen66
> next-auth 也非常黑盒，登录成功的响应竟然是 302 ，死活无法适配另一个 web app 。

next-auth 黑盒说不上，就是文档太差了，我遇到问题都是直接翻源码，它因为要适配各种情况，配置的确比较杂，像重定向之类 redirectTo 如果没有传，它会返回一个 response 就不给你做重定向了。

- 理由 1: 加班不给加班费
如果理由 1 不成立，可以用理由 2
- 理由 2：我是个人，我有个人生活，不想赚加班费

我看楼主的烦恼其实不是具体的技术方案，而是人和人的关系。
良好的团队氛围应该是可以用开放的心态一起讨论问题，其实很多方案也没有绝对的好和坏，要根据场景和其他的各种因素（比如 timeline ，扩展性，成本等）综合考虑，经常要做 tradeoff 。
如果意见不一致，就直接按 owner 的想法走就可以，谁 own 谁决定，谁决定谁负责。换句话说，楼主需要事先明确这个通信方案的最终 owner 是谁，如果是这位架构师，楼主配合就可以，事后如果方案不妥当要返工楼主不背锅就行；如果 owner 是楼主自己，架构师的方案不认同就拒绝。
最怕的楼主心里的 owner 是自己，但是老板心里的 owner 是架构师...

建议找老板聊一下，但是不要先聊技术方案，而是先明确组织关系和权责。

还在做协同编辑的话，可以考虑一下 https://github.com/instantdb/instant

来个假设法，假设那天吃饭 D 也去了，本来 3 个人吃 54 的，人均不变的话 4 个人吃了 18 * 4 = 72 元, 如果这样的话啥都不用调整。但是 D 吃完后吐回去给餐厅了：）并和 ABC 说他要把 18 元充回去给餐厅，往卡里充的 18 元对应到优惠后的现金是 18 / 11 * 10 = 180 / 11 元。
因为要公平，充钱，花钱都是 4 人一起操作的，所以 D 找 ABC 每人收 180 / 11 / 4 ≈ 4.09 元

> 技术只是工具，公司是业务驱动，技术没有话语权，需要让技术在公司变得重要，这个怎么做？
> 为团队争取了什么利益？
> 如何沟通，把想法传递过去，让老板接受去做一些业务上没多大收益，但是技术团队有收益的事？

三个问题有点关联，
业务驱动是没有错，技术在你们公司是可有可无的存在，还是负责落地的关键一环？如果没有技术你们公司也可以照样赚钱，那没什么话好说；否则的话，如果你想改变现状，可以让技术垮一次，不要去牺牲工作强度、挤压开发周期和流程去帮业务兜底，人教人教不会，事教人一次会。
老板要怪罪起来，你可以说主观上大家已经尽力了，但是客观条件（比如流程规范，时间规划等等）导致了事故频出，请管理层重视一下。另外你都会说业务比较复杂，原有的人又不敢动，也不用太怵老板换人。

总之，老板只有尝到苦头才会重视你们团队的诉求，你才有可能为团队争取利益。

同意 12 楼，尽量不写复杂逻辑，if-else 也尽量少用，多用 composition 和 polymophism 。
编码层面可以尽量用抽象的思维隔离开通用和特殊的处理，
业务层面可以让产品经理或者架构设计师尽量把复杂逻辑捋清楚或者简化/统一化，最佳实践是拿着测试 case/code 和 产品对一对。

@bclerdx 另外法定的赔偿没有 N+2 这种，只有 N, N+1, 2N 三种，平时我们所的 N 是补偿金， +1 是 1 个月的代通知金。
协商解约我们这里不讨论，法定解约的话一般就是 N ，如果是合同到期前提前的话要加 1 个月代通知金。如果违法解约就是 2N 。

@bclerdx 项目绩效行不行并不能构成公司合法解约的唯一条件。《劳动合同法》第四十条第二款“劳动者不能胜任工作，经过培训或者调整工作岗位，仍不能胜任工作的” 的解约，对于公司来说是非常耗费资源和时间的，实体要件和程序要件缺一不可，大致流程如下，有一点没做好就可能导致违法解约，所以比较少的公司会选择走这条路线。

- 具有明确的岗位要求或岗位职责说明；
- 考核制度经民主程序制定且已经公示；
- 具有不能胜任工作的证据，一般是绩效考核结果；
- 实际履行培训或调岗程序；
- 具有经培训或调岗后仍不能胜任工作的证据，一般是二次考核结果；
- 将解约理由事先通知工会、听取工会意见；
- 作出正式的解约决定并向员工送达解约通知；
- 依法支付经济补偿金等。

> 但是我们最开始定的规范是一个 get 方法都不用，全部用 post 方法放 json 里，

不知道为什么一开始定这样的规范，与其自己去定义一套新的，还不如去使用已被详细讨论过并被严格定义的行业规范，比如 https://jsonapi.org/format/#fetching

> http.get<ResultPage<SomeType>>("/test", params);
> 或
> http.get<ResultData<SomeType>>("/test", params);

这两个调用的参数一模一样，可以思考一下为什么你每次调用的时候知道该指定哪个返回类型？（ ResultData VS ResultPage ）
是不是其实 params 的类型是不一样的？
如果是的话，可以去定义 params 的类型，然后用 https://www.typescriptlang.org/docs/handbook/2/conditional-types.html ， 大致思路就是用 param 的类型去确定响应的类型。

另一个方式就是你去定义 UnionType ，比如 Result = ResultData | ResultPage, 你只用写 http.get<Resutl> ...
然后在使用返回的响应值的地方，用 TypeGuard （ https://www.typescriptlang.org/docs/handbook/advanced-types.html#user-defined-type-guards ）去 narrow down 具体的类型（ ResultData VS ResultPage ）

> 函数逻辑都想好了
> 但名字还没想出来

提供一个思路，我个人比较喜欢 top-down 的方式去写函数，而不是先去想逻辑。
即，先试图用一句话去描述这个函数是干什么的，可以不要管怎么实现（ how ），
最好能在概括的时候思考一下函数的输入输出，只要你一句短语说的清楚的话，名字也就容易起了。

如果先去想逻辑和具体实现的话，很容易形成一个局面，就是你最后定义函数是为了包装一堆可能
原本不该在一个维度的逻辑代码，这时候取名字就很难了。

换句话说，发现函数难以起名的时候，可能要思考一下是不是应该转换一下思路，做一下拆解或者合并；
至于命名风格问题，各个语言和框架都有行业上比较成熟的惯例，加上 lint 就可以了。

不容易，国内用函数式做主力编程语言的公司真是屈指可数 👍🏼

> 刚想了想，我感觉还是应该把“从 token 中获取用户信息”这一操作放到 api 层去处理，然后将用户信息或者其中某些字段作为参数传递到 service 中，service 只处理业务逻辑这样更好些。

对的，这就是写测试代码的好处，促使你重新思考分层 /解耦有么有做好，测试困难很可能代码设计就有坏味道了。

仅从题主的例子来说，
第 1 点不同是可读性，imperative VS declarative ，
第 2 点关于复杂度的担忧（循环），同样是函数式的写法可以用 fold / reduce, 另外尽量用 transducer ，看上去很多的 transformer 实际上也只是循环一次。(不清楚 java 是否有类似的东西，https://clojure.org/reference/transducers 是 clojure 在性能方面的考量和努力）

> 综上, 这个 store 是会在不同线程中批量或单独读取写入的, 那么, 有什么办法保证批量或单独读写的原子性吗?

不太清楚你这个 store 是什么，如果你有多个 node.js application 需要共享数据，最直接的就是把数据放在 database ( redis 也行）里，由 database 来保证原子性。