@iPhone12 #22
@willsank0430 #27
哈哈哈哈，我来和你说说他们为什么会这样杠；
之前也有很多小工具类的（基于 web ），都在说永久免费，但实测开发者热度一过，整个站点都无法使用。
我记得的对上一个是短网址生成的，也是刚弄出来救承诺永久免费，然后有人用他的 API 生成使用，过了半年不到项目就下线了，使用他 API 的基本都跟着 GG 。
就是类似的原因，所以一般建议个人形式开发者，提供源码的没什么好说，提供服务的就别说永久，毕竟不知道哪一天服务就停了。如果真的有人复用你的服务那他们就跟着挂了。
所以你别怪他们激烈了点，可能他们只是被坑多了。

@julyclyde #26
是否能直通我不确定（没试过），
pike 卡阵列芯片是 lsi 的具体型号忘记了。
我插上 pike 卡后是为了能用 sas2 接口而已，直通我觉得问题应该不大，但不确定

我自己掉坑的经历，有需要可以参考；
1 、硬盘 /电源--->买全新的；
*硬盘属于消耗品，就算店保，也没必要折腾。电源也是，你永远不知道卖家把电源改装到怎样，而且我机箱是全塔，所以不需要机箱电源，直接买好点的 PC 电源，双路的话注意 CPU 供电接口是否足够。

2 、主板：
直接买机房下架的主板，别去买什么华南 XX 之类的，我中过坑，那些高负载或满配下有问题。
*主板就算坏一般都是电容坏，自己淘宝相同型号替换就好了。

3 、CPU:
没什么好说的，尽量别买 ES 版本的，二手 CPU 坏几率真的十分低，而且服务器版也不用想超频这些，无论大雕小雕，只要稳定的就是好雕。

4 、内存：
也是二手的，去主板官网查文档，尽量选择文档中提及支援的内存品牌和参数的，二手 ecc 便宜很多，全塔式机箱就算 ecc 过热也能很好解决。
*在用的 X58 3 通道 DDR3 1333 ecc 全插满，用手摸会感觉很烫，但实际使用并没有出现不稳定，首次购买可以先跑 memtest 测试下，尽量选同型号。

5 、显卡 /声卡 /网卡
按需，但购买主板前需要查看是否有多额外插槽。
*我是额外买了显卡和声卡。

6 、阵列卡
asus 主板会带 sas 接口，但要使用的话需要额外购买专有的阵列卡（ pike ）名字不知道有没写错，我是买了个二手的，由于 x58 只支持到 sata2 ，所以插上 pike 卡后直接用 sas 接口，速度和 sata3 差不多，然后 ssd 接去 sas 口。
如果需要 nvme 的话建议再三考虑清楚，低端 nvme 完全不建议，二手 nvme 考人品的我自认黑人，高端 nvme 的话建议别买洋垃圾+扩展卡去使用。

功耗问题：
我是办公用的，所以对功耗没什么要求；
如果长期 24 小时开机，对性能要求不高但对功耗有要求，建议可以关注下 arm 架构；
如果对性能有要求，建议别买洋垃圾，毕竟架构>一切。

选购方式：
根据自己需求先确认主板型号---二手
*显卡数量的支持，原生 NVME 还是 sas/sata 即可等的..

根据主板选择 CPU---二手
*留意主板是否支持多路 /单路，一般单路频率会高

根据主板选择内存---二手
*留意主板和 CPU 是否支持

根据主板选择机箱--(全新 /二手)
*我喜欢支持背部走线和半透的

根据机箱和主板 选择 电源--全新
*我喜欢 模块化的如果双路需要注意 CPU 供电线要*2 ，
*由于我机箱是半透的，所以必须要支持背部走线，这样看起来不会凌乱；
*模块化的话电源线相对少

根据主板和机箱 选择 散热器--（全新 /二手）
*我选择九州风神*2 ，好像是 90 多一个吧，反正问题不大，只是留意下能否装入机箱和是否顶到显卡即可。

根据主板选择 硬盘--全新

二手件价格波动比较大，可以装个查价插件查历史价。
我全新的购买渠道都是 JD ，二手的购买渠道都是 TB 。

洋垃圾由来：
早期境外 IDC 机房有相关规定，如 CPU 、硬盘、主板、内存：使用周期最长 X 年，
到达 X 年后无论是否可用都需要替换下来，而替换下来的本土二手需求不高，但海外市场（我国）需求量比较大，所以就成批成批运送过来。
*为什么叫洋垃圾，和当时生态有关，那个时候境内还是机房托管 /VPS/主机租用的业务，早期的主机租用国内大多数 IDC 是租满 3 年送服务器产权，并且当时的 IDC 大多不是按无故障使用时间来替换硬件下来，而是用到不能用才替换下来，所以国内流出的服务器配件不算多，当然那时候也有类似（百度、新浪、网易）等的下架服务器，但对比入口的数量少很多。
而称之为垃圾，则是因为境外流入的二手拆机件大多数都是 达到 /快达到 无故障时间（ 3/5 年）类的，但 CPU/主板架构基本 1 年一变，意味着能买到二手拆机件基本是和现代架构有 1~3 代的相差，而且属于别人的淘汰件，所以称为垃圾。

但无论别人怎么看，我也觉得身为一个垃圾佬使我非常快乐。
我现在用的主机，双路 X58 L5630 64G DDR3 内存，自己使用了十多年了，战斗力还挺不错。
虽然没有 USB 3 和 NVME 这些，但这些对我而言也不是必须的。

@nanjingwuyanzu #8
轻量从哪里看都不符合 LZ 要求，极限才是 16C 。

1 、仿对标产品
2 、素材库--开个 VIP 下载 PSD
3 、看心情

@charlie21 #130
这些没有对错，一脚踢的情况下怎么方便怎么来；
分前后端的话要么听架构的话，要么听项目经理的话，何必自寻苦恼；
我觉得 LZ 的公司职能是后端支配前端部门。

而且这些也很难说按工作量去计算。
据我所知微信小程序部门，一个人负责一个组件（比方 button/textarea ）或 api 。
可是他们的福利也比很多公司要好 :dog

@charlie21 #125 实际项目往往都会出现他说的那种场景；
一开始数据量小的时候，订单详情一个接口就把数据跑出来了，大家都方便。
数据量大了的时候，汇聚的接口返回 JSON 大小几百 KB ，开启 GZIP 的情况下，后端负载还算可以，但前端浏览器已经卡成狗了。
这个时候就需要拆分接口，先出列表，然后用户点开信息的时候，分开加载。
这种场景我遇到过两次，

一次是产品列表，
productList
|--spuList
|----skuList
开始的时候是分页返回 10 条 productList,里面汇聚了 spuList 和 skuList 的信息；
但对接某平台后，单个产品有几十个的 spu ，一个 spu 里有上百个 sku 。
浏览器直接崩溃，后来拆分接口，productList & spuList 汇聚 skuList 单独查询。

另一次是订单详情，
orderInfo
|--orderList
|----.....
|--personList
|---....
|--orderLog
|---....
|--payLog
|---....
|--.....
主订单包含一堆子订单，子订单关联不同的供应商，订单操作日志和财务信息等。
和上面一样，一开始都是把这堆信息打包到 JSON 里一次加载出来，
但实际使用后，由于 personList 和 orderList 是可以修改的，导致每次修改后都要重复载入，
最后只能才分开各自一个接口，哪一块操作后就加载哪一块的数据。
后期供应部分还对接的第三方平台，线上发单后的结果是异步返回的，所以针对供应状态也独立一个接口进行查询。

业务上线后，改动居多的都是前端部分，后端不可能因为“方便”前端，而把自己也“耗”进去吧。

有没有可能：
GET bookinfo-->缓存静态信息
GET bookOrderInfo --->缓存静态信息
POST bookorderInfostatus ---> 实时状态信息。
为了方便做数据缓存？

>token 登录态，如果快过期了，提供了个刷新 token 的接口给前端，喊前端发现 token 要过期了就去刷一下接口
这个我觉得没问题啊，你请求里的 token 过期了，你去刷新一下这个 token ，有什么问题呢？而且刷新后 token 值也不同了，后端也无法帮你替换成新的 token 值啊，而且这个你请求拦截时检查下不就好了？

我一直不明白 PHP 究竟哪里性能不行了？（不拿 PHP8 ，就说 PHP7 来说）
真的是到达了语言性能瓶颈了吗？
我猜测大部分项目，性能的瓶颈主要在于服务器网络带宽和数据库，而并非语言框架。
redis 、mq 、elk ，这些 PHP 都有扩展可以支持使用。
如果你觉得 phpfpm 性能不行，那你可以尝试 swoole 或 webman （ workman ）框架。

而且就如上面很多人提到，为何非要耗死在一种语言身上呢？
语言只是个工具，
对于把钉子锤进墙里，我觉得锤子比打桩机好用。

开源：uview 1.x （复杂页面性能相对差，模板少了点，但 ui 比较好看）
收费：graceUI （很方便，页面组件，支持 nvue ，坑比较少，模板还算可以，ui 个人觉得没 uview 好看）
收费：nPro （ nvue 下比较方便，主打性能，样式挺好看，模板和组件相对少）

@caqiko
不优秀，只是被社会打磨得越来越圆滑罢了，现在 966 而已。
以前接触 ZF 的，基本对方对接都是一群 50+的，前期完全不管，后期天天跑来公司叫外卖拍照发他们工作群。
需要提高预算就一拖再拖，有问题就直接把外包推出来挡刀。
以前很好奇为什么政务办不成立个自己的技术部，这样他们各局的需求自行开发即可，慢慢我就明白了还是找外包好的道理，所以身为外包，肯定要有那么一两招防身

刚开始使用 uniapp 生成微信小程序，确实一堆问题，大致上是生成后的 v-show 在微信小程序中会导致报错；
至于其他的坑我还没遇到过，前几排说一堆坑不知道能否举例一两个？
通过 uniapp 开发过 2 个 APP 在运营，6 个微信小程序，1 个抖音小程序，3 个 H5 页面，其中一个项目是 APP 、微信小程序、H5 、抖音小程序 一起的，但是多平台编译换来的代价是一堆条件编译，看起来很凌乱。
都是基于 VUE2 开发的。
NVUE 下尝试过，但一堆不支持多到怀疑人生，本来 weex 的怪异现象就多了，所以不多说了。
而 VUE3 没记错是最近 3 个月左右才开始支持的吧？不稳定完全正常啊，而且 vue2 又不是不能用。

flutter 、uniapp 、taro 两个分水岭，taro 和 flutter 我没使用过不清楚，但 uniapp 使用快 1 年了，开发效率真的挺高，而且有一个项目涉及到境外的某个支付平台 SDK 调用，自己把 SDK 包装下暴露接口给 uniapp 调用就行了。

当然 uniapp 的文档和论坛基本可以理解为缺少支持，但免费商用的你还想怎么样，并且付费的话就能得到商业支持。

我接触到的，比较大型的公司喜欢选择 flutter taro 这两样，外包和个人开发者倾向 uniapp 。

但我觉得这些东西不是不能喷，而是纯属的喷毫无意义，喷一样东西的时候，先把问题说清楚再去喷，而不是一味说“垃圾、一堆坑、用不了、他不行” 这样的话。

对于一个免费商用支持的东西，你不喜欢大不了直接不用，没必要到处黑他吧？
你能开发一个同等的出来并免费商用，然后去喷他怎样怎样，那我能理解；
你开发不了同样的东西，但你能指出他的坑和缺点，我能理解你是为了让后人避坑；
你既开发不了同样的东西，又不指出坑在哪，自己却一直在用他来输出，到处去喷他有问题，我真的无法理解这种做法。

上面漏了，压测，记得要出压测报告；
如果是基于小程序的，小程序本身有压测功能，量大的付费即可，别想省这笔钱，反正也不多；
但是记得保存压测结果。
到真出什么问题的时候，拿出报告；
1 、如果使用人数>压测人数，真要问责你就把压测结果拿出来，说我们按照这个预期人数设计的，但实际参与人数多了 xxxx ，然后一般都没问题，切记合同上要轻描淡写提及下并发数量。
2 、如果使用人数<压测人数，直接甩锅微信，压测报告中.....但实际情况....问题本身是微信压测结果不精准，我们能做的已经都做了，只是没想到微信压测会如此，下一步我们会加强自建压测平台，bababababa....

支付宝不清楚；微信有支付券的，去和微信支付谈就行了。
也不涉及到核销的问题，消费券核销情况微信有接口拉取回来或异步通知的。
抽象点的说法：
客户抢卷->API->微信支付(创建消费红包)->微信通知用户现金券到账。
客户消费->微信支付->通知核销现金券（和消费商家没关系）

至于上面提到的风控问题，微信小程序有风控接口；
上面提到核销问题，和商家无关，是客户使用微信支付时候选择消费红包；

然后你自己需要关注的就是一个地方，用户抢卷的时候会是典型的高并发场景；
可以考虑:

小程序形式，（有图片的就上 CDN ）自己服务器别负担静态流量
抢卷的时候别直接发请求，做个定时器，随机 100~3000 毫秒才发送请求，界面就显示个 loadding ；（万金油，能避免并发的问题）
拦截器，请求超时提示 网络异常，请稍后再试。（把锅先甩了）
创建失败--一般是达到微信 QPS 或后端请求微信创建失败类的原因，就提示 微信异常，请稍后再试（不粘锅，能甩先甩）

jsbridge 是通讯方式而不是跳转方式吧，我的理解...
我不清楚你的广告跳转是要怎样跳转，如果是单纯的 h5 跳转，让开发写个 webview 的页面，开屏点击后跳转去 webview ，然后该干嘛干嘛。
如果是想 h5 跳转打开其他 APP ，那就需要通过 JSBridge 来交互。

我觉得主要是在于理解，上面的流程图可圈可点.....

web 服务----NGINX/iis/....
应用服务---django 、flask 、.....


1 、浏览器是解释 html/js/css 语言的，这个万变不离其宗；
2.1 、涉及转发 /代理类型的，由 web 服务进行转发请求，获取结果后响应给浏览器;
2.2 、不涉及转发，则本地查找静态文件，响应给浏览器；
3 、浏览器根据响应的结果进行渲染

--jQuery 时代[特指前后端混合的时期]
一般所有请求都会转发给应用服务，应用服务会把完整的代码返回给浏览器；
后面 ajax 开始普片，大部分是 html 画个模板，数据通过 ajax 请求返回。

--vue/react 时代
前后端完全分离，前端搭建好框架，所有数据由后端提供；
*此时引出一个问题就是后端和前端的开发并不同步，前端需要测试数据的时候后端还没写好接口，mock 就出现了，伪装返回数据（当然返回数据格式自己写，按和后台的约定即可）。
*另外浏览器访问本地文件是受限的，所以 IDE 一般内置一个小型 web 服务，以此来缩小线上和开发环境的距离，而且方便。

无论 ajax 或 vue/react ，他们共通点都是数据根据 api 接口返回，但搜索引擎无法针对纯 API 返回数据进行高效索引，也无法索引到 vue/react 的代码（因为只有骨架没内容）。所以对搜索引擎收录是不友好的，此时就有针对这个问题的解决方案 SSR ，如果方位时标识为搜索引擎，返回一段简单的 html 代码+数据，如果是正常浏览器访问，则按正常形式返回。

题外话，无论请求流程怎么转，万变不离其宗的就是发出请求，收到响应。
但是我做过一个项目由于图片比较多，且后期才加入 COS 服务的，做法上：
浏览器->CDN->COS-> NGINX-> PHP
浏览器发出请求：1.jpg
CDN:检查是否有 1.jpg 的缓存，没有就去 COS 拉取；
COS:检查是否有 1.jpg 文件，没有就去 NGINX 拉取；
NGINX:检查是否有压缩的 jpg 文件(默认只返回 w750;q.8 的)，没有则转发给 PHP;
PHP:返回原图，同时把图片加入 redis_queue 里面，队列形式进行压缩。

不过后来 COS 有图片压缩功能后，直接就把 PHP 那块砍了....

*其实中间经历了什么主要是看你怎么配置，这个不是浏览器关注的，就好比谁做省长我无所谓，我只要做省长夫人即可。

美团没开放这些接口，携程有开放，但申请条件比较高，我只是对接过驴妈妈的，
驴妈妈是 PULL + PUSH 形式，一般每个月全量拉一次，后续产品信息变动会 PULL 对应的 ID 过来，然后再拉指定 ID 的信息即可。
基本每个 OTA 的接口数据都不一样，自己做下 mapping 就行了。