不太清楚你说的是 nextjs 什么版本，是 pages router 还是 app routers,
但是在 build 阶段，nextjs 会做一些优化比如 SSG(server site generation)，所以你会发现“这个 .env 内容在 build 阶段就会替换进代码中”，我比较建议.env 只在本地开发使用，在 CI （比如 github action)上和部署环境上就不用 .env 文件而是显示指定环境变量，
你可以参考一下我这个项目，可以看到 builder 和 runner 上是分别指定环境变量的。
https://github.com/xavierchow/xblog/blob/ba3e0efcfd42226bee15fb51f45681e752f70a93/Dockerfile#L27-L41

更多的关于 build with docker 的细节另外也可以参考这篇 blog： https://xavierz.dev/blog/posts/xblog_pipeline

@FaiChou

只要有每个月的工资流水和社保缴纳记录，你的劳动关系认定就没有问题，签合同是公司的法定义务，如果公司一直不主动找你补签合同的话，你看以下法律条款，你总是不亏的。

> 2.用工之日起超过 1 个月不满 1 年未订立书面劳动合同的处理 用人单位自用工之日起超过 1 个月不满 1 年未与劳动者订立书面劳动合同的，应当依照《中华人民共和国劳动合同法》第八十二条的规定向劳动者每月支付两倍的工资，并与劳动者补订书面劳动合同；劳动者不与用人单位订立书面劳动合同的，用人单位应当书面通知劳动者终止劳动关系，并依照《中华人民共和国劳动合同法》第四十七条的规定支付经济补偿。
> 3.用工之日起满 1 年未订立书面劳动合同的处理 用人单位自用工之日起满 1 年未与劳动者订立书面劳动合同的，自用工之日起满 1 个月的次日至满 1 年的前一日应当依照《中华人民共和国劳动合同法》第八十二条的规定向劳动者每月支付两倍的工资，并视为自用工之日起满 1 年的当日已经与劳动者订立无固定期限劳动合同，应当立即与劳动者补订书面劳动合同。

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 就可以了。

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