检查下 能运行的那个环境的 php 扩展

其实说到底还是深度广度的事情。
有些事情，光有广度是不够的。（某些专业的事情是需要深度的这个没毛病吧）
在有些情况下，光有深度也是然并软的。 一个纯后端和一个纯前端，两人没有共同涉猎部分的话（如 web 前后端的传输协议），也是鸡同鸭讲。

就看你觉得自己知识的广度广到什么范围、深度深到什么位置比较适合自己所想的模样。

比如未来规划是分布式服务，那前端的 browser 相关的东西都不用了解。
如果是一个有一定架构能力，能协调各个部位的全栈，那么对广度就有一定的要求了。

PS：
程序员往一个方向干久了，就会变成了针对某一个位置的非常好用的齿轮（专家），然后一旦环境变了。。。。。。
如果是啥都懂。拥抱变化就比如方便，不过一旦遇到某些非常深的问题，要么硬啃，快速学习变成半个专家，要么直接找专家。。。
所以两种人都是被需要的。最后还是要看你自己的未来规划。

最后，保持学习，个人认为最重要的不是当前的能力水平，而是快速学习和保持不断学习的能力。

三维不能改？
简介不能换行？

PS： 图棱角是不是多了点。。。

@Kilerd #9 可能我对 cookie & session 的描述不太清楚。

2. axios 在浏览器中使用会使用 xhr 来进行请求（在 node 环境中会使用 node 的 http 库），xhr （不管你用 jq 还是啥，这些库发起的异步请求最后都是采用 浏览器的 xhr 或 fetch 接口来进行的。）（包括 fetch 也是）会根据 同源策略来自动附加同域的 cookies，对于跨域请求，则不会带 cookie，需要前端显式设置传递 cookies 并且 后端也显式允许传递 cookies 才会传递 cookies。

3. 这可能是每个人对 cookie & session 界定的不同而导致的。
session 是个概念。由于 HTTP 协议是无状态的，但很多情况是需要状态的，也就是 会话管理（ session ）。
session 的实现方案有很多种（比如 url 里带唯一标识）。一开始大家都各搞各的，93 年网景发明了 cookie 也就是 浏览器端的状态管理机制（ rfc-2109 也定义了 cookie ）
可以说 cookie 是 session （会话管理） 的一种客户端实现。

1.
>> HTTPS 无法加密 URL 内容。新版提案在促进这个过程
HTTPS 无法对中间人保密“访问的站点”（即中间人知道你访问了哪个域名 or ip ），但中间人看不到具体路径。

2.
>> 前后端分离时 ：并且前端采用 axios 来构建一个 HTTP 连接时，不会自动加上 Cookies，所以 Cookies 在前后端分离中并不能使用。

不自动带 cookie 是因为 cors 的原因，这锅 axios 不背。合理的 cors 策略可以自动带 cookie 的。

3.
>> Session 是依赖 Cookies 存在的，所以在前后端分离中自然不能使用。

sessionID 不放 cookie，让前端每次放 header 里可以不？
sessionID 就是个 token
session 是个后端技术，cookie 是个前端技术，两者通常一起被使用。并不是谁归属于谁。

4.
>> 简单来说，JWT 是 Token 的具体且应用广泛的实现。
>> 上文讲到 Token 可以理解成为用户自己实现的 Session，那么 JWT 在某种程度上可以理解为自己实现的 Cookies
这两句是不是矛盾了？

jwt 你也可以只在 payload 里存个 id 啊。

5. session 最常见的不是 文件 + 内存 么。。。

@azh7138m #23 是很常见啊，不过都是针对文本内容的。对于 图片、字体、媒体资源，依然可以知道总大小。

PS：
gzip 一般是在 content-encoding
Transfer-Encoding 一般才是 chunk

gzip 是可以得知 length 的。不过就需要 server 用 buffer 缓存压缩后的内容，全部压缩完后得到大小在发送（比较伤，所以一般 server 采用 gzip、br 等后就分块传输（可以流式编码了））。

而对于 js、css 等文本资源，一般文件较小的没有加载进度的需求吧，只有数量较多、总体较大的文件要加载时，才有这个需求，如果服务器不返回 size，则可以采用 已加载数量 /总数量 的方式。

@azh7138m chunk 传输才没有 content length，一般来说流式传输动态内容时才会使用 chunk，普通静态内容都是非 chunk 的

@learnshare #13 进度变小，你可以倒退，也可以等待啊。
有没有必要做，看需求和收益，不是单看复杂不复杂，真有需求，写个 loader 又何妨呢。
LZ 只是问怎么做。我给了答案。
做不做，看 LZ 自己喽。

@learnshare #8
1. 链接建立拿到 header -> 更新 total size
2. 拿到内容 -> 更新 current size
如：
1s：189 / 800
3s: 772 / 1723
5s: 2300 / 2300 done!


或者

当前文件进度：123 / 6123B
总进度: 26 / 89 个

因为对于浏览器来说，加载资源可能是多个同时进行的。所以后者不好做。 前者就够了。

原理：
http header: Content-Length 表明了响应的总长度。
当前接受到的 ／ Content-Length = 进度

实现：
xhr 的 progress Event
fetch 的 Response.body 上的 getReader() , render 可以读原始字节流，然后计算当前进度。

设置 app store 自动安装更新

我记得 webview 可以自己拦截所有请求的吧。正常代理这些请求，把响应中是图片的保存下来。

上面的方案我没试过，不过可行性有的

不过我做过 用 webssh + docker 的方式 可以达到你的目的

试试把登录的 shell 改成 docker run -it --rm alpine sh ？

@huiyifyj #7 看起来是网络问题
你是 linux 机器， 试试这个

``` shell

npm config delete proxy

export HTTP_PROXY=http://127.0.0.1:1080
export HTTPS_PROXY=http://127.0.0.1:1080
npm config set http-proxy=http://127.0.0.1:1080
npm config set https-proxy=http://127.0.0.1:1080


# 先试一下能不能访问
curl -Ssv https://registry.npmjs.org/proxy-pac.js
# ok 的话 在提交一次试试
npm publish

```

把 log 贴到 gist 然后 append gist 地址