第一个敌楼

我现在正在进行 信用生活 的业务运行系统的开发，使用了 AngularJS 以及 Material Design 以及 [Angular UI Router]()，系统中涉及到了一个特别常见的问题——一个Router的网址带有可选的参数，比如：/cms/promotions/movies 对应的是 /cms/promotions/:promotionType ，然后我还需要网址中能带有分页参数以及每一页数据的条目数量参数，这些参数也还应该有默认值，这个时候就使用到了可选参数。

在 AngularJS UI Router 中有以下方法可以创建可选参数的路由。

Query Parameters

使用 Query Parameters 是最简单也是最常见的一种方式了， UI Router 会将定义的参数都添加至 $stateParams 对象中去，比如：

state('app.console.cms.promotions', {
  url: '/cms/promotions/:promotionType?page',
  templateUrl: 'app/console/cms/promotions/promotion-list.tmpl.html',
  controller: function($scope, $stateParams) {
    $scope.promotionType = $stateParams.promotionType;
    $scope.page = $stateParams.page || 0;
  }
})

接着，你就可以向下面这样定义一个新的链接了：

<a ui-sref="app.console.cms.promotions({ promotionType: 'foods', page: 1})">美食</a>

如果有多个参数，也没有关系，直接把多个参数使用 & 符号连接即可：

state('app.console.cms.promotions', {
  url: '/cms/promotions/:promotionType?page&size',
  templateUrl: 'app/console/cms/promotions/promotion-list.tmpl.html',
  controller: function($scope, $stateParams) {
    $scope.promotionType = $stateParams.promotionType;
    $scope.page = $stateParams.page || 0;
    $scope.size = $stateParams.size || 10;
  }
})

直接使用 Route Parameter

还有一种方式只适合只有一个可选参数的路由，比如：/cms/promotions/:promotionType：

state('app.console.cms.promotions', {
  url: '/cms/promotions/:promotionType',
  templateUrl: 'app/console/cms/promotions/promotion-list.tmpl.html',
  controller: function($scope, $stateParams) {
    $scope.promotionType = $stateParams.promotionType || 'foods';
  }
})

此时， /cms/promotions/ 就对应的就是参数没有值时的路由了，此时我在 Controller 里面使用了一个默认的 foods 值为其值。

但是对于多个参数的时候，我们也只能定义多个路由了：

state('app.console.cms.promotions', {
  url: '/cms/promotions/:promotionType',
  templateUrl: 'app/console/cms/promotions/promotion-list.tmpl.html',
  controller: function($scope, $stateParams) {
    $scope.promotionType = $stateParams.promotionType || 'foods';
  }
})

...

state('app.console.cms.promotions', {
  url: '/cms/promotions/:promotionType/:page',
  templateUrl: 'app/console/cms/promotions/promotion-list.tmpl.html',
  controller: function($scope, $stateParams) {
    $scope.promotionType = $stateParams.promotionType || 'foods';
    $scope.page = $stateParams.page || 0;
  }
})

非 URL 路由参数

还有一种方式，可以不通过 URL 即可定义参数：

state('app.console.cms.promotions', {
  url: '/cms/promotions',
  params: {
    promotionType: 'foods'
  },
  templateUrl: 'app/console/cms/promotions/promotion-list.tmpl.html',
  controller: function($scope, $stateParams) {
    $scope.promotionType = $stateParams.promotionType;
  }
})

此时，我们还是可以使用 ui-sref=app.console.cms.promotions({promotionType: 'movies'}) 创建一个链接 /cms/promotions，但是却会把 movies 做为 promotionType 的值传递给控制器。

Accept

客户端用 Accept 首部来通知服务器 可以接受哪些媒体类型，其值就是客户端支持的媒体类型列表，比如 image/gif 就是表示客户端支持 gif 格式的图片， * 则是一个特殊的值，用来通配媒体类型，比如 */* 表示所有媒体，image/* 则表示所有的图片，同时，还可以添加一个质量值 q 来告诉浏览器优先选择哪种媒体类型。

示例

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

Accept-Charset

客户端用 Accept-Charset 首部来通知服务器，它可以接受哪些字符集或者哪些优选字符集，其值为多个字符集列表以及字符集可能的质量值，当服务器上有以多种可接受字符集表示的文档时，可以通过质量值告知服务器哪个字符集是优选的，该首部同样有一个 * 通配符。

示例

Accept-Charset: iso-latin-1

Accept-Encoding

客户端用 Accept-Encoding 首部来告知服务器它可以接受哪些编码方式，如果服务器的内容是经过编码的（可能是经过压缩的），那么这个请求首部可以告诉服务器客户是否会接受它。

示例

Accept-Encoding: gzip, compress;q=0.5

Accept-Language

客户端用 Accept-Language 表示可接受或者优选哪些语言。

示例

Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4

Accept-Ranges

Accept-Ranges 首部与其它 Accept 首部不同——它是服务器使用的一种响应首部，用来告诉客户端它们是否接受请求资源的某个范围。如果这个首部有赋值的话，这个值就说明了服务器允许对指定资源的哪个范围类型进行访问。

客户端可以在没有收到这个首部的情况下，对某资源发起范围请求。如果服务器法巴拉圭对那个资源的范围请求，可以以适当的状态码（比如 416）进行响应，奖 Accept-Ranges 的值设置为 none ，客户端以后就不会（也不应该）再发起范围请求了。

应用场景

该首部最常见的应用场景就是断点下载，当我们从网络上下载一个大小为 4096 bytes 的文件时，可能下载到 2048 bytes时，网络中断了，这个时候，如果再次下载，我们就可以通过一个客户端的 Range 首部告诉服务器，我只需要下载 2049 bytes 之后的数据即可，前面的数据已经有了（这个在后面会讲到），当然，这需要服务器返回一个正确的 Accept-Ranges 值 bytes。

另一个常见的场景就是在做 RESTFul 接口时，比如一个用于查询所有用户列表的接口 /users，可能数据库里面总共有 10000 条记录，但是我们不可能一次性就全部返回，这个时候，服务器可以返回一个 Accept-Ranges: items ，告诉客户端，你可以以 items 类型对该资源进行部分下载。

示例

Accept-Ranges: bytes

Age

Allow

Allow 首部经用于通知客户端可以对特定资源使用哪些HTTP方法。

示例

Allow: GET, HEAD

Authorization

Authorization 首部是由客户端发送的，用来向服务器回应自己的身份验证信息，客户端收到来自服务器的 401 Authentication Required 响应后，要在其请求中包含这个首部，这个首部的值 取决非于所使用的认证方案。

示例

Authorization: Basic YnJpYW4tdG90dHk6T3ch

说明

在有一些时候，我们可能也不会使用这个首部，而是使用自己定义的相类似的首部，比如在信用生活的项目里面我们使用的就是 X-Auth-Token，这个时候，但是使用这种自定义的首部之后，通用的客户端就无法为我们进行任何建议或处理了，就像在浏览器里面，若服务器返回 401 Authentication Required，这个时候，浏览器表现为弹出一个输入用户名和密码的输入框 ，用户输入之后，浏览器会对其进行简单的 Base64 编码，然后直接重新发起一次请求（本次请求会带上如上面示例所示的首部），但是对于服务器来讲，因为认证并不是通过 Authorization 首部进行的，所以还是会返回 401 响应。

Cache-Control

Cache-Control 首部用于传输对象 的缓存信息，这个首部是 HTTP/1.1 引入的比较复杂的首部之一，它的值是一个缓存命令，给出了某个对象可缓存性有关的缓存 特有指令。

示例

Cache-Control: no-cache

Client-ip

这是一个在一些比较老的客户端和代理上面会出现的首部，用于表示运行当前客户端或者代理的计算机的IP地址。

示例

Client-ip: 10.106.4.199

Connection

Connection 首部是个多少有点过载了的首部，它可能会把你搞晕。这个首部用于 扩展了 keep-alive 连接的 HTTP/1.0 客户端， keep-alive 连接用于控制信息，在 `HTTP/1.1中，能识别出大部分较老的语义，但这个首部被赋予了新的功能。

在 HTTP/1.1 中，Connection 首部的值 是一个标记列表，这些标记对应各种名称，应用程序收到带有 Connection 首部的 HTTP/1.1 报文后，应该对列表进行解析，并删除报文中所有在 Connection 首部列表中出现过的首部，它主要用于有代理的网络环境，这样服务器或者其它代理 就可以指定不应该传递的逐跳首部了。

比如 close 这个标记值，这个标记意味着响应结束之后，连接会被关闭，不支持持久连接的 HTTP/1.1 应用程序要在所有请求和响应中插入带有 close 标记的 Connection 首部。

示例

Connection: close

Content-Base

服务器可以通过 Content-Base 首部为响应主体部分中要解析的 URL 指定一个基础 URL ，其值是一个绝对 URL，用于解析在实体内找到的相对 URL。

示例

Content-Base: http://www.onmr.com/

Content-Encoding

Content-Encoding 首部用于说明是否对某对象进行过编码，通过对内容进行编码，服务器可以在发送响应之前将其进行压缩，然后通过 Content-Encoding 首部的值告诉客户端，服务器对对象执行过哪种或者哪些类型的编码，有了这个信息，客户端就可以对报文进行编码了，这个值，理论上来讲应该是由客户端发送的 Accept-Encoding 首部中所有支持的编码类型的一个子集。

示例

Content-Encoding: compress, gzip

Content-Language

Content-Language 首部用来告诉想要理解对象的客户端，应该理解哪种自然语言，比如说，一篇用法语编写的文档就应该有一个表示法语的 Content-Language 值。

示例

Content-Language: en

Content-Length

Content-Length 首部说明了主体部分的长度或尺寸，如果对 HEAD 请求的响应报文中带上这个首部，则这个首部就告诉客户端，如果要发送内容的话，那么内容主体的长度就是这个值。

示例

Content-Length: 2417

Content-Location

Content-Location 首部包含在一个 HTTP 报文中，给出了与报文的实体部分相对应的 URL ，对可能有多个 URL 的对象来说，响应报文中可以包含一个 Content-Location 首部，说明用来产生响应的对象的 URL ，Content-Location 可以与所请求的 URL 不同，服务器通常会用它奖客户端导向或者重定向到一个新的 URL 上去。

如果 URL 是相对的，就应该相对于 Content-Base 首部加以解释，如果没有提供 Content-Base，则应该使用请求的 URL 进行解释。

示例

下面的示例就是信用生活中，信用卡信息管理接口 /api/v1/discovery/creditcards ，当我使用 POST 请求，向服务器发送了张新卡片详情数据之后，服务器完成数据的校验与保存，然后返回一个 Content-Location ，告诉客户端，新的内容的位置在哪里：

Content-Location:/api/v1/discovery/creditcards/1600

Content-MD5

Content-MD5 首部是服务器用来对报文主体进行报文完整性检查的，只有原始服务器或发起请求的客户端可以在报文中插入 Content-MD5 首部，首部值就是报文主体的 MD5 摘要（根据 RFC 1864 的定义，MD5 摘要值是一个 Base64 或者 128 位的 MD5 摘要。

示例

Content-MD5: YnJpYW4tdG90dHk6T3ch

Content-Range

请求传输某范围内的文档时，产生的结果由 Content-Range 首部给出，它提供了请求实体所在的原始实体内的位置（范围），还给出了整体实体的长度。如果值为 *，而不是整个实体的长度，就意味首发送响应时，长度未知（这个我们在使用浏览器下载文件的时候，绝大多数情况下，我们都是可以根据当前网速知道剩余下载时间的，但是有一些下载，我们却不知道下载时间，这就是因为，在下载时，服务器明确表示了内容长度未知引起的）。

示例

下面的示例就表示了，内容的长度单位为 bytes，总长度为 5400 bytes ，而本次响应的内容为整个主体对象第 500 - 999 bytes 间的内容。

Content-Range: bytes 500-999 / 5400

应用场景

这个首部在我来宜人贷的这段时间内，还没有看到哪个项目或者团队在使用，但是在我自己的项目里面使用到了，我自己项目的接口是完全基于 RESUful 建议的，这里面就以 /user/users 接口为例来讲讲，该接口的 GET 请求用于查询数据库中的所有用户，默认情况下，服务器会返回查询到的前20条记录，现在假如整个库中有 1000 个用户，那么， /user/users 这个资源主体大小就是 1000，因为这里面的大小单位不再是 bytes ，所以，我们自己定义了一个单位 items，当客户端 GET /user/users 时，会得到下面这样的首部：

Content-Range: items 0-19/1000

此时，客户端已经得到它所需要的所有信息了：

1. 当前资源返回的是第0至第19个
2. 资源总条目（items）数为 1000

在接下来的访问过程中，客户端就可以发起请求，获取其它范围的内容了，比如下面这样：

Range: items=20-39

这时，服务器就知道，此次请求需要查询的是第20至第39个条目

说明

关于 RESTful 中的分页，我现在的解决方案如下：

• 请求格式：Range: items=start-end
• 响应格式：Content-Range: items start-end/total

Range 首部

Range 首页由客户端发送请求时携带，用于标识此次请求需要服务器端返回哪个区间的数据，Range的取值方式如下：

1. items=0-9：取结果集中的 第0至第9 个子集
2. items=1000-：取结果集中 第1000及其以后所有数据 的子集
3. items=-500：取结果集中 最后500个 子集
4. items=0-9,20-29：取结果集中 第0-9个 以及 第20-29个 两个子集的合集
5. items=0-9,-9：取结果集中 第0-9个 以及 最后9个 两个子集的合集

Content-Range 首部

Content-Range 首部是由服务器在返回结果的响应时，携带的首部，用于表示此次返回的数据的范围，其值如下：

Content-Range: items 0-9/100

详细的说明可以见 http://git.onmr.com/grassroots/grassroots-api-docs/blob/master/structure.md。

关于 Range 首部，会在 Range 首部中专门细说一下。

Content-Type

Content-Type 首部说明了报文中对象的媒体类型。

示例

Content-Type: text/html; charset=iso-latin-1

Cookie

Cookie 首部是用于客户端识别和跟踪的扩展首部。

示例

Cookie: sessionid=IDFIOSDUFSDFLKIU@#IOL#KKJoi

Cookie2

Cookie2 首部是用于客户端识别和跟踪的扩展首部，Cookie2 用于识别请求发起者能够理解哪种类型的 Cookie1。

示例

Cookie2: $version="1"

Date

Date 首部给出了报文创建的日期和时间，服务器响应中要包含这个首部，因为缓存在评估响应的新鲜度时，要用到这个服务器认定的报文创建时间和日期，对客户端来说，这个首部是可选的，但包含这个首部会更好。

HTTP 有几种特定的日期 格式，这种格式是在 RFC 822中定义的，这是 HTTP/1.1 报文的优选格式，但是在早期的HTTP规范中，没有明确说明日期的格式，因此服务器和客户端的实现者使用了一些其他 格式，为了解决这些遗留问题仍然需要支持这些格式：

Date: Tuesday, 03-Oct-14 02:15:31 GMT RFC 850 format
Date: Tue Oct 3 02:15:31 1997 asctime( ) format

示例

Date: Thu, 07 Jan 2015 15:15:15 GMT

ETag

ETag 首部为报文中包含的实体提供了实体标记，实体标记实际上就是一种标识资源的方式。

示例

ETag: "11e92a-457b-31345aa"
ETag: W/"11e92a-457b-31345aa"

W/ 前缀广播一个 弱 实体标记，对于弱实体标记来说，只有当关联 的实体在语义上发生了重大改变时，标记才会变化 。

Expect

客户端通过 Expect 首部来告知服务器它们需求某种行为，现在此首部与响应码 100 Continue 紧密相关。

如果服务器无法理解 Expect 首部的值，就应该以状态码 417 Expectation Failded 进行响应。

示例

Expect: 100-continue

Expires

Expires 首部给出了响应失效的日期和时间，这样，像浏览器这样的客户端就可以缓存一份副本，在这个时间到期之前 ，不用去询问服务器它是否有效了。

示例

Expires: Thu, 07 Jan 2015 15:15:15 GMT

From

From 首部说明请求来自何方，其格式就是客户端用户的有效电子邮件地址。

示例

From: name@domain.com

Host

客户端通过 Host 首部为服务器提供客户端想要访问的好地台机器的因特网主机名和端口号，主机名和端口号来自客户端所请求的 URL。

如果一台服务器上面服务着多个网站，每一个网站绑定了一个独立的域名，这个时候，服务器软件就需要通过 Host 首部来判断用户是需要访问当前该服务器上面的那一个网站了。

HTTP/1.1 客户端必须在所有请求中包含 Host 首部，所有的 HTTP/1.1 服务器都必须以 400 Bad Request 状态码去响应没有提供 Host 首部的请求。

示例

Host: onmr.com:80

If-Modified-Since

If-Modified-Since 请求首部用来发起条件请求，客户端可以用 GET 方法去请求服务器上的资源，而响应则取决于客户端上次请求此资源之后，该资源是否被修改过，如果对象未被修改过，服务器就会回送一条 304 Not Modified 响应，而不会回送此资源，如果对象对修改过，则服务器就会像非条件 GET 请求一样进行响应。

示例

If-Modified-Since: Thu, 07 Jan 2015 15:15:15 GMT

If-Match

与 If-Modified-Since 首部类似，If-Match 首部也可以用于发起条件请求，If-Match 请求使用的是实体标记（ETag）而不是日期。服务器将对比 If-Match 首部的实体标记与资源当前的实体标记，如果标记匹配就将对象返回。

服务器应该用 If-Match 值 * 与资源拥有的所有实体标记进行匹配，除非服务器上没有这个资源了，否则 * 总会与实体标记相匹配。

示例

If-Match: "11e92a-457b-31345aa"

If-None-Match

与所有 If 首部一样，If-None-Match 首部可以用于发起条件请求，客户端为服务器提供 一个实体标记列表，服务器将这些标记与它拥有的资源实体标记进行比较，只在都不匹配的时候才将资源返回。这样缓存就可以只在资源已被修改的情况下才更新。通过 If-None-Match 首部，缓存可以用一条请求使它拥有 的实体失效，同时在响应中接收新的实体。

示例

If-None-Match: "11e92a-457b-31345aa"

If-Range

与 If 首部一样，If-Range 首部可以用于发起条件请求。应该程序拥有某范围内资源的副本，它要对范围进行再验证，如果范围无效的话，要获取新的资源，在这种情况下会使用这个首部。

示例

If-Range: "11e92a-457b-3134b5aa"

If-Unmodified-Since

If-Unmodified-Since 与 If-Modified-Since 是一对，该首部查询时，未被修改过才返回对象。

示例

If-Unmodified-Since: Thu, 03 Oct 2015 17:17:17 GMT

Last-Modified

Last-Modified 首部试图提供这个实体最后一次被修改的相关信息，这个值可以说明很多事情，比如，资源通常都是一台服务器上的文件，因此 Last-Modified 值可能是服务器的文件系统所提供的最后修改时间；对于那些动态创建的资源，Last-Modified 的值可能就是创建响应的时间。

Location

Location 首部可以将客房端导向某个资源的地址，这个资源可能在客房端最后一次请示之后被移动过，也可能是在对请示的响应中创建的。

示例

Location: http://www.onmr.com/press/http-headers

Max-Forwards

这个首部必须和 Trace 方法一同使用，以指定请示所经过的代理或者其它中间节点的最大数目，它的值是一个整数，所有收到带有此首部的 Trace 请示，都需要在请示转发出去之前，将该值减1。如果应用程序在收到请示时，这个首部的值为0,就要向请示回应一条 200 OK响应，并在实体的主体部分包含原始请示。

示例

Max-Forwards: 5

MIME-Version

MIME-Version 用于提供服务器支持的 MIME 版本，老服务器才可能存在，没有进入标准中。

Pragma

Pragma 首部用于随报文传送一些指令，这些指令几乎可以包含任何内容，但通常会用这些指令来控制缓存的行为。Pragma 首部的目标可以是接收这条报文的所有应用程序，因为此理和网关一定不能将删除。

最常见的形式，比如用户点击刷新按扭或者重新加载时，浏览器一般都会带上 Pragma: no-cache 首部，用于强制在有新鲜副本可用的情况下，向原始服务器请示文档或对其进行再验证。很多服务器也会向客户端发送 Pragma: no-cache 首部的响应（作用与 Cache-Control: no-cache 等价）

规范中唯一一个被定义的指令就是 no-cache

Proxy-Authenticate

Proxy-Authenticate 与 WWW-Authenticate 类似，当代理服务器发送了一条 407 Proxy Authentication Required 响应时，发起请示的应用程序就必须包含 Proxy-Authenticate 首部。

示例

Proxy-Authenticate: Basic realm="Yirendai Super User"

Proxy-Authorization

Proxy-Authorization 被客户端用来响应代理服务器的 Proxy-Authenticate 声明

Proxy-Connection

Proxy-Connection 与 HTTP/1.0 Connection 首部类似，

Public

Public 首部可让服务器告知客户端其支持哪些方法，今后客房端就可以在发起的请示中使用这些方法了。

示例

Public: OPTIONS, GET, HEAD, TRACE, POST

Range

在请示某个实体的部分内容时，会使用到这个首部

示例

Range: bytes=500-1000

Referer

在客户端的请求中插入 Referer 首部，可以使服务器知道客房端是从哪里获取到其请示的 URL的，这是一种对服务器有益的自愿行为，这样服务器就可以更好的记录请求，或执行其它任务。

浏览器所做的工作非常简单，如果在主页Ａ上点击了一个金田白立，进入主页Ｂ，那么浏览器就会在请求Ｂ的请求中带有一个 Referer 首部，其值为主页Ａ的ＵＲＬ。

Retry-After

服务器通过 Retry-After 首部告知客房端在什么时候可以重新发送某资源的请求。

Server

Server 与 User-Agent 类似，服务器使用该首部来标识自己。

Set-Cookie

Set-Cookie 用于告知客户端设置 Cookie

Set-Cookie2

对 Set-Cookie 首部的扩展

TE

Accept-Transfer-Encoding ，类似于 Accept-Encoding，只不过它用于定义传输编码。

Trailer

Trailer 首部用于说明报文拖挂中提供了哪些首部。

示例

Trailer: Content-Length

Title

Title 发送 HTML 文档的标题（非标准）

Transfer-Encoding

Transfer-Encoding 定义报文的传输编码。

示例

Transfer-Encoding: chunked

UA-(CPU,Disp,OS,Color,Pixels)

非标准

Upgrade

User-Agent

Vary

Via

Warning

WWW-Authenticate

X-Cache

X-Forwarded-For

X-Pad

X-Serial-Number

分层系统穿衣法能够优化服装的交通和通用性，更能够适应山区气温的波动，便于登山者根据所需进行调整，以最轻的重量让身体保持最大的舒适感。大多数有经验的登山者都会总结出套自己的穿衣方法，在野外根据特定的环境或者个人爱好做相应的培养，要么改变内层朵么多带或者少带几件保暖衣，要么带不同的外套（检验该产品），但有一点始终不会改变，那就是分层穿衣原则。分层穿衣原则的“分层”是指贴身内层，保暖层和外层。

贴身内层

内层衣服应该选择排污性较强的内衣，以保持身体的干爽。排污对于保暖来说非常重要，因为湿衣服在皮肤上会加剧体温的流失。选择什么质地、品牌的贴身内层衣物因人而异，但一定要满足透气、保暖、排污的需求。

长内衣

合适的长内衣能够起到良好的保暖作用。聚丙烯和聚酯纤维是多数人的选择，当然也有些人偏爱毛织品。深色的长内衣吸热性强，能让身体保持温暖，在阳光下也容易干。浅色的长内衣吸热性能一般，适合在夏天穿，同时还能防晒伤和防蚊虫叮咬。

攀岩时，攀登者偶尔会用弹性织物和聚酯纤维混纺的紧身衣来代替长内衣，因为前者有更好的延伸性，活动自如，但保暖性不如后者。

T恤和短裤

虽然T恤、短裤、普通内衣、运动衣等并未在身体周围形成一层真正的保护层，但它们也扮演着非常重要的角色。

在酷暑里，因为不需要靠衣物排污，所以棉质T恤或者无袖的上衣比较好。如果要防晒，最好穿长袖衣服。需要注意的是，在凉爽的山区，不适合穿棉质T恤，因为微风容易让棉质T恤被汗水浸透。在休息时，湿衣服会让人冷得浑身发抖。在这种环境中，不吸尘的合成纤维比棉质衣服更合适。T恤最好选择浅色、不紧身的，才能凉爽和通风。

短裤必须且有耐磨性和透气性。一件宽松的尼龙短裤，加上​一件尼龙网眼内裤就能达到这种效果，登山者不宜穿棉内裤，这是因为汗湿的棉质内裤容易擦伤皮肤，感觉不适。在气候宜人时，轻抚聚酯纤维长内衣加上一条尼龙短裤是登山者最爱的组合。可拆解成短裤的轻抚尼龙长裤也是非常受欢迎的。

保暖层

保暖层应该包住人体周围的温暖空气，这层空气越厚，人就会感觉越温暖。穿数件宽松的薄衣服虽然不如穿一件羊绒大衣保暖，但可以一层一层的保住明空气，也方便调节。

天气寒冷时，就需要穿上数层衣物保暖。上身可选择较厚的长内衣，毛料或合成纤维衬衫、毛衣、羽绒夹克或者人造纤维填充料的夹克。腿部可选择厚卫生裤、毛料长裤或者弹性较好的尼龙裤。在严寒时，建议穿连身的保暖衣物，市场上的保暖衣服品种丰富，它们可以确保登山者的衣服在涅槃的情况下仍能保持身体温暖。

衬衫和毛衣

衬衫和造谣要足够长，这样才能把它们指扎进裤腰或者拉出来盖到腰部。长裤和上半身衣物间的空隙会散失宝贵的温暖空气，高领内衣和造谣的保暖效果很不错，而且也较轻。

保暖长裤

比较宽松或者具有伸缩性的长裤是首选，这种长裤有利于自由伸展。长裤的面料质地应紧密，并经过防风或耐磨处理。毛料裤或毛料与聚酯纤维混纺裤做长裤也很好，羊毛裤虽然轻但不防风，也不耐磨，请选购臀部和膝部有加强设计、腿侧有拉链的款式，这样的款式在使用冰爪或滑雪板时能顺利穿脱。

七分裤

有不少的登山者比较喜欢及膝的七分登山裤加绑腿的搭配，本分裤便于活动和通风，裤腿也不会被雪或露水沾湿，便于保持干爽。

皮质大衣

在非常寒冷的环境下，皮质大衣是登山队员尤其是确保队员非常适合的保暖衣服，它中以把大个子衣服都包裹进去。这种皮质大衣有头套，且质量轻、可压缩，还有不错的防水性能。

外层

外层衣物一定要能够防风、防雨和防晒。

理想的外层衣服应该具有防风、完全防水及完全透气的功能。在现实中，虽然没有一件衣物能够完全达到这些要求，但我们可以用不同的穿衣方法来达到上述目的。

一种方法是穿上一层多功能的防水透气外层，如果这层衣物透气性足够好，那么它就是最好的选择。

另一种方法是穿两层外层衣物：一层轻质透气的风衣和一层轻抚雨衣（不管是否透气）。在轻风细雨时可穿风衣，雨势较大时再穿上雨衣。这种穿衣方法比较省钱，在不下雨时穿风衣也利于通风，但不透气的雨衣没有防水透气雨衣舒适，且携带两件衣物也增加了负重。

连帽雨衣

连帽雨衣款式众多，标准连帽雨衣前面有可调节通风度的全开式拉链。有的人偏爱套头式雨衣，因为这种雨衣质量轻、体积小，防风性也比较好。不论雨衣的材料是否具有透气功能，选购时要考虑的关键因素都相同。

雨裤

雨裤的侧边最好要有拉链，可以在穿鞋或者冰爪时轻松穿脱。雨裤的穿着频率较雨衣低，而且在穿越灌木丛或从雪滑降时容易磨损，所以选择比较便宜的非透气型雨裤比较实用。

有些登山者采用防水透气型吊带裤作为下身外层，这种选择适合较冷的山区。有些吊带裤内有保暖填充料，非常适合进入严寒山区。这种裤子比一般雨裤伸腰，因为它包裹住了大部分身体，可以避免雪从腰部裤子的缝隙中掉入裤管，但这种吊带裤夏季穿时就会太热。此外，也有一部分登山者倾向于选择具有单一保暖性的雨衣裤。

• 将登山行程表交给营地留守人员；
• 带足上山的衣物、食物和装备；
• 一个登山队至少应有三人，除非事先做了足够的准备；
• 在攀登冰河时，建议至少组建两个绳队；
• 在没有任何遮蔽物的冰河上行进时，请用绳索确保，并固定所有的确保点；
• 集体行动，听众领队或者服从多数人的决定；
• 不要攀登超出你知识水平和能力范围的路线；
• 选择走哪条路或者考虑是否返回时，别因冲动作决定；
• 遵照公认较好的登山指南介绍的登山守则；
• 任何时候都要以友好的态度对待山林，严格遵守“不留痕迹”原则。

人类正以惊人的速度消耗着大自然，对自然造成无法挽回的破坏。山林并不是为了登山者而存在，它不欠人类任何东西，对人类也无所欲求。

按阳历算，又是新的一年了，今年元旦跟温新泽同学两个人过的，去年在蓝色港湾和三里屯，今年在后海，近两点才回到家。尔后白天去了798，陪小泽同志去了一躺中关村买了个35的定焦头，认识了张老师（玩摄影玩了40多年，从高中时代就开始玩，现在已经退休，烧设备也烧了40多年，我只想问一下下，算下来在北京有多少套房子了？只是业余爱好哦），然后接着去了躺鸟巢，好好的拍了几张，还算有一两张满意的吧。

听了张老师的一段教导，记录下：

1. 拍下来的任何照片，都存好源始档案，胶片机的话，就存好胶片，数码机的话，相机出出来的文件保存到电脑上之后就再也不要动，所有的操作都使用复本，然后，记录好每一张照片的拍摄地点，时间，以及当时相关的一些场景；
2. 任何照片，当你按着自己的构图拍好了之后，后退一段距离（定焦的话）或者焦距小一点，拍一张比自己构图视角要宽一点的图片，以防万一一张好的照片因为构图时候的不注意少了点什么；
3. 如果想要提高出片率，任何时候，都请使用三脚架，即使是炎炎夏日，即使天气好得不了，即使太阳当空照，不要相信自己手持有多稳当，放大之后都是扯蛋；
4. 如果想要提高出片率，照片可以一次加减1、2、3、4、5档曝光，也就是一张照片有11个曝光（如果相机支持的话，不支持一般也支持上下三档即共七档），这可以让你永远都有更多的机会选出一张正常曝光的照片；
5. 不要还没开拍就想着怎么后期，一张好的照片应该是拍出来的时候的，只有在因为某些技术原因，拍的时候产生一些瑕疵的时候，再使用后期技术做一些修复，但记住，只是修复，不是修改；
6. 胶片相片影响出片率的主要是镜头，但不要相信所谓摄影大师说所说的，数码时代，机身很关键，远远超过镜头，2000W像素和4000像素就是差很多，不要在技术进步之后，还把自己局限在古老的时代，我以四十年设备发烧玩家的经验告诉你这些；
7. 我长住山西，“十年中国看深圳，百年中国看上海，千年中国看北京，三千年中国看陕西，五千年中国看山西”，有时间，去山西太原找我，我可以带你好好玩玩。

上几张今天拍的照片