楼主提出的观点其实总共有 3 个：
1、雷电的电气成本（物料成本）高
2、因为 1，未来可能有通货膨胀导致雷电的实际价格高
3、因为 1，雷电很难普及


而 @BingoXuan 反驳的其实主要是第 2 第 3 点
2、雷电不止有固定成本（物料成本），也有边际成本（研发推广成本），后者是正在下降的
3、因为 2，对雷电的普及有更好的预期


其中，楼主更看重第 1 点结论，@BingoXuan 更看重第 3 点结论。
我觉得二位讲的似乎都没有错误，只需要搞清楚双方所针对的点就好了。

类似的事，上次在微信群讨论的时候被其它人喷了，但是我还是想表达一下想法：

我不会主动去 “卡” 任何组员的请假，不管是调休还是事假。
但我不希望组员给我搞 “突然袭击”，只给我留极少的时间处理。
作为项目的负责人，我有责任保证即使成员请假，项目也能顺利进行。

我也有我的汇报对象，我也需要给他们一个交待：
组员请假的影响，是否在我的可控范围内？我是否做好了相应安排？项目计划是否会受到影响？

如果出现了 “工作未安排” 的请假，我确实会很焦虑，因为这是失控的情况。
我会做好准备，避免单个组员的突发情况导致项目停摆，但那是预防措施，如非必要我不希望启用。

我期望的状态是，除非事出紧急，组员在请假时，能够将心比心，主动提前告知我，
这并不是我 “不情愿” 你请假或者设置障碍，而是希望整个组整体的利益最大化。
事实上大部分情况下的 “安排”，也就短短三五句话沟通工作，真的占用不了多少时间。

注意，我强调了 “除非事出紧急”，如果确实是紧急情况，自然以急事为主，
这种情况下，只要说一声就够，甚至事后再说也行，请假手续也更是无所谓。



你有随时请假的权利，主管有不批假的权力，在诉求权利或使用权力时，其实都可以更柔和一些，
要求自己应得的权利是没有任何问题的，只是如果做事时多互相考虑一下，可能就减少了许多冲突。

类似的情况我在之前的帖子 154 楼有回复，也可以参考一下：/t/522131

另：
领导下班不先走其它人就不能走或不好意思走，我不知道哪来的这个规定，我觉得这是氛围问题。
反正我一般都是最后一个走的，组员事不多就正常下班，事很多的话我就跟着一起加班处理问题。
包括如果临时有事，周六需要某一两个人加班，我也会跟着一起加班，不知道这样做算不算工贼。

@lcdtyph #11
首先我觉得你预设了楼主认为 “一定拿到真实 host ” 的需求，我没有看到楼主要求这个。
楼主问这个的原因，我猜测是因为 BaseHTTPServer 没有 self.host，让楼主有些懵如何自己获取。

相对应的，例如 flask 有 flask.Request.host，django 有 django.http.HttpRequest.get_host，都可以直接取。
https://flask.palletsprojects.com/en/1.1.x/api/#flask.Request.host
https://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpRequest.get_host

那么他们都是怎么取的呢？我比较懒，只翻了 flask，层层追溯可以找到这里：
https://github.com/pallets/werkzeug/blob/master/src/werkzeug/wsgi.py#L145

而 django，其实上面贴的文档里已经讲了，相比直接去 host 字段，还考虑了反代的场景。


至于：ssl 卸载靠 web server，反代的时候直接把 sni 信息塞进一个 header 转发给 simplehttpserver 就行了。
不妨调研一下，想要实现这样的效果，应该怎样去具体实现，怕不是要写个 nginx 插件才行？


最后，关于 “ webserver 是可信的”，不妨看一下著名的 WebServer Nginx 是怎样处理请求的：
http://nginx.org/en/docs/http/request_processing.html

我想，你应该能看到大量的 ' “ Host ” header field ' 这样的字眼，我就不多说了。

@lcdtyph #8
一个 “恶意” 的客户端，如何做到：
让 Web Server 拿到正确的域名（从而正常分发 vhost ）
却又
不让 Web Application 拿到正确的域名（从而无法取出 host 字段）

请注意：
只传递正确的 SNI，但传递错误的 host 字段，不但会欺骗 Web Application，
事实上在 Web Server 也会被欺骗，此时就已经跑到错误的 vhost 去了。

另外如果采取 SNI 的方式，你的 SSL 负载要靠 Web Server 来卸载 还是靠 SimpleHTTPServer 来卸载呢？
靠 Web Server 来卸载的话，哪儿来的 SNI 信息呢？靠 SimpleHTTPServer 卸载的话，好像不支持吧？
以及，我甚至不需要考虑恶意的客户端，对于 IE6 IE7 这种不支持 SNI 的浏览器，是不是又变成了拿不到了呢？

其实并不是：SimpleHTTPServer 没有“一定”能拿到域名的方法。
而应当是：任何的 Web Server 都没有 没有“一定”能拿到域名的方法。


在当前的环境下，我认为 HTTP 1.1 可以当做事实上的最优选择。

@lcdtyph #5
根据我从下面的代码看到的情况，是可以支持 1.1 的（确切来说，是支持 1.1 的 keepalive 特性），
不过需要手动设置一下 protocol_version （ # Set this to HTTP/1.1 to enable automatic keepalive ）
https://github.com/python/cpython/blob/2.7/Lib/BaseHTTPServer.py#L270
https://github.com/python/cpython/blob/2.7/Lib/BaseHTTPServer.py#L513

另外，host 字段是否存在，其实主要取决于你发起请求的客户端使用的版本啊，你 1.1 的请求已经自带 host header 了。


当然，假如你一定要考虑 1.0 的请求，其实也有一定可能能从 URI 里读取到的：
https://tools.ietf.org/html/rfc1945#page-24
翻到这里发现一件事，那就是 1.0 时，如果这样读不到，其它的 Web Server 也读不到，不用纠结。

@lcdtyph #2
HTTP 1.1 的标准里，header 里的 host 字段是必须的

参见 RFC： https://tools.ietf.org/html/rfc2616#page-129

A client MUST include a Host header field in all HTTP/1.1 request messages .

like this ？

https://www.ifanr.com/minapp/1200484

第一反应就是 pjax

在我的理解中，节点等效于 “分类” ，一个主题只能从属于一个节点。

我其实更喜欢 TAG 的组织形式，因为一个主题可以具备多个 TAG，而 TAG 之间可以设置一些 “联动机制” 来实现更智能的覆盖。


SO …… 想问下站长是否有看到之前提的有关 TAG 的工单帖子，是否有考虑修复呢？

https://www.v2ex.com/t/583207

退款或确认收货（也就是订单完成）后投诉就可以了。

上次朋友买了 1000 多的啤酒，卖家不但不按时发货，还一直欺骗说货物已经发出只是物流的系统有问题。

一波投诉赔了 300 多回来，继续在那家买了啤酒 hhhh （当时淘宝还没有现金红包，赔的是可以无门槛抵现的某个积分，记不清叫什么了）

@kafkaonsea #13
有人说偏白，但是我用黑苹果单屏没有感觉到

如果 user topic 这两个结构，在其它接口中也有出现，且结构逻辑统一，我觉得第一种更好一些。

如果这只是一个单独的接口，我觉得两种都可以接受。
但是第二种对客户端来说，在反序列化的时候会更方便一些。

AOPEN 24CH2QK 在用，做工非常一般，但显示效果完全可以接受，还可以壁挂。
京东自营+售后，配合 PLUS 券以后 1250 拿下，是个蛮便宜实惠的选项。

本来想无脑推荐 Pixel c 的，看到预算表示算了 hhhh