@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 就行了。

@oblivion #69
建议媒体处理，真按流程，估计你忙不过来。

@oblivion #69 按正规流程，你每个案件都要案外人异议。


@skiy #68 我不是总盯着法院，而是我认为不合理的就应当提出，而不是墨守成规。当然在这里说再多也不会影响到实际情况。
法院我还真没去过，只去过检察院，旁边就是法院，占地面积和检察院差不多，人员不清楚，不能说十分大，但也不算小。

>一个区（县）只有一个法院，却有 N 个派出所。法院没有能力所有的事都亲力亲为的。如果法院有这能力做完全部，律师也就没啥用了。
首先就是你看清楚我上条回复的内容吧，我没说需要法院去做真实核验，而是说流程上直接把被冻结人的身份信息提供给相关单位，由相关单位对身份证关联的账号执行冻结。而不是根据上诉人要求的“账号”直接进行冻结；

另外，并不能说因为机构少人员少，就没必要亲自亲为，这是什么观点来的...不能因为兵少就不打仗，也不能因为警察少就不抓坏人吧？


>法院有二次确认的权力不错，但“附带冻结手机号”这种事情，我不觉得法院会再次确认。如果说是附带“冻结联系人银行账号”这类，我觉得才有可能。
在百度查询到，法院没有对 银行卡 进行二次确认，也没有说属于失职（搜索结果），当然实际工作纪律我不清楚。所以二次确认不确认这个，我依然觉得，法院只需要提供被执行人的身份证号码给相关机构就好了，不需要法院进行核验和二次确认。

@skiy #61
刚也去看了相关材料，事实的确如此，流程上：
1 、申请人（提供材料）
2 、法院审核（通过的话执行内容）
3 、由于法院是根据申请人提交的线索进行判决，如果有误，法院不存在责任，而是该追究 提供线索的人（即申请人）的责任，但法院有二次确认的权力，所以一般不会错。（来自百度）
如果真的错了，案外人可提出申诉，要求法院停止冻结，但一般冻结不会产生财产变动，所以不会有赔偿。

但我认为以上流程是落后的...
现在公民信息已经联网了，在执行内容里面，甚至不需要法院二次确认，就如上面我所说的，
法院只需要尽判决的职能即可，
比方需要冻结我的资产，
法院只需要提供我的身份证给银行，由银行检索出我的账户并进行冻结即可。而不是根据申请人提交的 账号 进行冻结，毕竟有可能提供的账号 ≠ 被执行人的账号。

@skiy #56
我个人认为的是，法院不需要“审查”，而是分派其他单位“协办”；就好像银行提出“冻结”申请，法院把被执行人的“身份证”发出给协查单位如：移动电信..，由移动电信根据身份证号在自行的系统中进行冻结处理。

而上面的回复就是这个意思，即法院仅执行判断，执行具体内容 按 身份证号码 下发给其余单位，其余单位根据身份证信息对自己系统中的进行冻结。而不是 直接根据上诉人申请需要冻结的账户直接冻结。





@TArysiyehua #55 你和我一开始想法一样，但现实就如 @skiy 所说的，法院是直接把 银行提交申请冻结保全的 账户 进行冻结。

@markgor #53 [补上]执行任何冻结拘留等的，都是以身份证作为前提的...