@ArronJun 微信应该是有代金券，支付宝可能叫商家红包。具体的得调研下。如果让商家走你的支付平台的话，就涉及个最后分账的逻辑，因为用户支付的钱是到你的账户下了。

依托于支付宝微信可以借助他们的身份系统避免一部分黑产刷券。核销得看怎么和商家对接了，粗略想的话提供给商家提供一套核销后台，然后还要有一套 OpenApi 核销接口用来对接需要接入自家平台的商家。最后对个账，划个款。就是财务的事了。

马上 2022 年了，我还手搓万物是不是太落伍了。。。

可以随便写 写大点 单位是字节

response header 加下 Content-Length 试试

@css3 那个。。 如果另一块屏只运行 ssh 是不是和共享键盘效果一样

试过绿联的对拷线和 synergy 。最后惊奇的发现 synergy 这种纯软件竟然比绿联流畅

合同很简单啊。没附件吗？功能清单之类的。
整个项目就按 6.5 万来算的话。
1. UI 成本
2. 需求调研成本
3. 销售提成？
4. 公司税费
5. 公司利润
剩下的才能用来实际开发。我建议你做好最坏的打算，就是软件公司根本没有实际开发能力完成你的需求。
如果你们签的合同里只有下面这些，说实话合同对于你没啥优势
（ 1 ） APP 项目开发
（ 2 ）各基础接口的对接
（ 3 ）各基础账号的申请
（ 4 ）测试阶段的必要调整

没有

我日常六七个 ide 和其他的乱七八糟软件，也是温热。不过风扇确实不转

@kujio 貌似不让包含问号。

兄台你看我的建议如何：
isVisiable => visiable 吗
isSelected => selected 吗

sha256sum 开头多了一个大写 T

@james2013 感觉 es 唯一的问题就是多了套运维成本，如果考勤数据涉及更新的话也要做两套数据维护。「由于根据公司 id 查询考勤记录的语句比较多」这个条件我觉得可以看时间维度，比如说按月分表，月表里在按公司 id 查询。可以根据你们的表结构和常用 sql 做下单表压测。来确定按时间分表的颗粒度。我理解考勤这种数据时间跨度最长不会超过一年，也就是说如果按月分表的话最多也就广播 12 个库。理论上是可以接受的

分库如果用的中间件。「根据公司所在的省份 /城市,公司名称关键字」这两个条件可以转成公司 id 。然后用 in 保证分片命中率。「打卡人姓名关键字」这个目前看没什么特别好的办法，不过也可以先根据姓名模糊匹配到所有公司 id 。具体得看匹配到的公司 id 多不多，要是太多的话也没啥提速。
（题外话：考勤数据是不是按时间分库比较好，查询时把时间作为必选值）

京东瞅瞅？ 去宠物店看看？

汪汪队？

太棒了！您的隔离区为空。对不起我实在忍不住哈哈哈哈哈哈哈

@tiRolin 我简单运行了一下你的代码暂时没发现问题。可以说下你 jdk 的安装方式和下载途径么？图片的话你可以自己找个图床上传然后把地址贴上来