（点击上方微信公众号，可快速关注）
Part.1
POST概念简介
关于网页POST，很多人都让我讲一讲，其实吧，我觉得POST就是构造一个“内容”顺利被访问网站接受并给予正确的反馈，这里面突破了类似浏览器等“约束”，只通过代码就实现了我们所想要的“网页访问”，因为大部分这类的需求是通过POST这个访问方式实现的，而我们易圈似乎已经这类网页访问俗称为“POST”。
Part.2
三要素
从“底层逻辑”上去分析，实现POST访问成功无外乎以下这个三要素：提交信息、协议头、Cookie（这个分类可能不够严谨，但我觉得很实用）——
1. 提交信息。我觉得这是POST的最核心部分，以登录而言，主要是把一些关键信息，如账号、密码等一些形式，进行打包，然后提交给服务器的数据。这些数据可以是简单的键值对，也可以是复杂的JSON对象或其他格式的数据。
2. 协议头。英文表示为Header，协议头类似于访问的一些固定要素，少了它，可能会访问失效或者失败，它的主要内容有很多，我们常用的可能是包含User-Agent、Content-Type、Referer、Accept等等。
3. Cookie。其实cookie严格意义上也在协议头的范畴里面，但是单独拿出来就说明了它的重要性，在某些情况下，Cookie也是POST请求不可或缺的一部分。Cookie用于在多个请求之间保持会话状态，通过在POST请求中包含正确的Cookie，客户端可以证明自己的身份或继续之前的会话。
Part.3
代码解读
返回值类型：字节集
参数<1>的名称为“网址”，类型为“文本型”。注明：完整的网页地址,必须包含http://或者https://。
参数<2>的名称为“访问方式”，类型为“整数型”，允许接收空参数数据。注明：0=GET 1=POST 2=HEAD 3=PUT 4=OPTIONS 5=DELETE 6=TRACE 7=CONNECT。
参数<3>的名称为“提交信息”，类型为“文本型”，允许接收空参数数据。注明："POST"专用 自动UTF8编码。
参数<4>的名称为“提交Cookies”，类型为“文本型”，接收参数数据时采用参考传递方式，允许接收空参数数据。注明：设置提交时的cookie。
参数<5>的名称为“返回Cookies”，类型为“文本型”，接收参数数据时采用参考传递方式，允许接收空参数数据。注明：返回的Cookie。
参数<6>的名称为“附加协议头”，类型为“文本型”，允许接收空参数数据。注明：一行一个请用换行符隔开。
参数<7>的名称为“返回协议头”，类型为“文本型”，接收参数数据时采用参考传递方式，允许接收空参数数据。注明：返回的协议头。
参数<8>的名称为“返回状态代码”，类型为“整数型”，接收参数数据时采用参考传递方式，允许接收空参数数据。注明：网页返回的状态代码，例如：200；302；404等。
参数<9>的名称为“禁止重定向”，类型为“逻辑型”，允许接收空参数数据。注明：默认不禁止网页重定向。
参数<10>的名称为“字节集提交”，类型为“字节集”，允许接收空参数数据。注明：提交字节集数据。
参数<11>的名称为“代理地址”，类型为“文本型”，允许接收空参数数据。注明：代理地址，格式为 8.8.8.8:88。
参数<12>的名称为“超时”，类型为“整数型”，允许接收空参数数据。注明：秒|默认为15秒,-1为无限等待。
参数<13>的名称为“代理用户名”，类型为“文本型”，允许接收空参数数据。注明：用户名。
参数<14>的名称为“代理密码”，类型为“文本型”，允许接收空参数数据。注明：密码。
参数<15>的名称为“代理标识”，类型为“整数型”，允许接收空参数数据。注明：代理标识，默认为1，0为路由器。
参数<16>的名称为“对象继承”，类型为“对象”，允许接收空参数数据。注明：此处可自行提供对象，不再主动创建。
参数<17>的名称为“是否自动合并更新Cookie”，类型为“逻辑型”，允许接收空参数数据。注明：默认为真，自动合并更新。
参数<18>的名称为“是否补全必要协议头”，类型为“逻辑型”，允许接收空参数数据。注明：当附件协议头为空时自动添加必要的UA协议头 默认为真，假将不再添加非传入协议头。
参数<19>的名称为“是否处理协议头大小写”，类型为“逻辑型”，允许接收空参数数据。注明：将协议头中的键名首字母处理为大写 默认为真。
网页_访问_对象（网址，1，提交信息，提交Cookies，，附加协议头）Part.4
进阶答疑
1. 如果POST这么轻松，为啥我老是实现不了呢？为啥市面各类定制费用都很高呢？
