引用自 http://ruby-china.org/topics/10414

做为热身，从一些简单的例子开始,

def f1yield
enddef f2(&p) p.call end def f3(p) p.call end f1 { puts "f1" } f2 { puts "f2" } f3(proc{ puts "f3"}) f3(Proc.new{puts "f3"}) f3(lambda{puts "f3"}) 

若你用的是ruby1.9及以上的版本，还可以这样,

f3(-> {puts "f3"}) 

上面是block, proc和lambda的一些基本用法。

block

先说说block, ruby中的block是方法的一个重要但非必要的组成部分，我们可以认为方法的完整定义类似于，

def f(零个或多个参数, &p) ... end 

注意&p不是参数，&p类似于一种声明，当方法后面有block时，会将block捕捉起来存放到变量p中，如果方法后面没有block，那么&p什么也不干。

def f(&p) end f(1) #=> 会抛出ArgumentError: wrong number of arguments (1 for 0)异常 f() #=> 没有异常抛出 f() { puts "f"} #=> 没有异常抛出 

从上面代码的运行结果可以知道&p不是参数

def f(a) puts a end f(1) { puts 2} #=> 没有异常抛出，输出1 

所以任何方法后面都可以挂载一个block，如果你定义的方法想使用block做点事情，那么你需要使用yield关键字或者&p

def f1yield
enddef f2(&p) p.call end 

此时f1, f2执行时后面必须挂一个block，否则会抛出异常，f1抛出LocalJumpError: no block given (yield)的异常,f2抛出NoMethodError: undefined method 'call' for nil:NilClass的异常, ruby提供了block_given?方法来判断方法后面是否挂了block，于是我们可以这样修改f1和f2，

def f1yield if block_given? end def f2(&p) p.call if block_given? end 

这样的话,f1和f2后面无论挂不挂block都不会抛异常了。
我们再来看看f2修改前抛出的NoMethodError: undefined method 'call' for nil:NilClass异常，这种说明当f2后面没有挂block的时候p是nil，那么我们给f2挂个block，再打印出p，看看p究竟是什么，

def f2(&p) puts p.class puts p.inspect p.call end f2 {} # 输出Proc和类似<Proc:0x007fdc72829780@(irb):21> 

这说明p是一个Proc实例对象，在ruby中，&还可以这么用，[1,2] & [2,3] 或者 puts true if 1 && 1 或者在某个类中将它作为一个方法名。

很多ruby老鸟会写类似下面的代码,

["1", "2", "3"].map(&:to_i)，其效果和["1", "2", "3"].map {|i| i.to_i }一样, 但简洁了许多，并且更加拉风。
这里的魔法在于符号&会触发:to_i的to_proc方法, to_proc执行后会返回一个proc实例， 然后&会把这个proc实例转换成一个block,我们需要要明白map方法后挂的是一个block，而不是接收一个proc对象做为参数。&:to_i是一个block，block不能独立存在，同时你也没有办法直接存储或传递它，必须把block挂在某个方法后面。

:to_i是 Symbol 类的实例, Symbol 中的to_proc方法的实现类似于，

class Symboldef to_procProc.new {|obj| obj.send(self) } end end 

同理我们可以给自己写的类定义to_proc方法,然后使用&耍下酷，比如，

class AddBydef initialize(num = 0) @num = num end def to_proc Proc.new {|obj| obj.send('+', @num)} end end add_by_9 = AddBy.new(9) puts [1,2,3].map(&add_by_9) #输出 [10, 11, 12] 

在ruby中, block有形,它有时候是这样

 do |...|... end 

有时候是这样

{|...| ...} 

或者类似 &p, &:to_i, &add_by_9之类，但是它无体，无体的意思就是说block无法单独存在，必须挂在方法后面，并且你没有办法直接把它存到变量里，也没有办法直接将它作为参数传递给方法，所以当你想存储，传递block时，你可以使用proc对象了，

 p = Proc.new(&:to_i) p = Proc.new {|obj| obj.to_i } p = Proc.new do |obj| obj.to_i end p = proc(&:to_i) p = proc {|obj| obj.to_i} p = proc do |obj| obj.to_i end def make_proc(&p) p end p = make_proc(&:to_i) p = make_proc do |obj| obj.to_i end p = make_proc {|obj| obj.to_i } 

虽然我在开发中经常用到block，但是我很少显式地去使用Proc或proc去实例化block，比如我几乎没有写过这样的代码,

  f(Proc.new {|...| ...}) f(proc {|...| ...}) p = Proc.new {|...| ...} #然后在某个地方p.call(...)或者将p传递给某个方法，比如f(p) 

在使用block时，我会忽略proc的存在，我将proc定位为一个幕后的工作者。我经常写类似下面的代码，

  def f(...) ... yield ... end def f(..., &p) ... p.call ... end def f(..., &p) instance_eval &p ... end def f(..., &p) ... defime_method m, &p ... end 

有些新手会写类似下面的一执行就会报错的代码,

  def f(..., &p) instance_eval p end def f(..., p) instance_eval p.call end 

也有这样写的,

  def f(..., &p) instance_eval do p.call end end 

或者

  def f(...) instance_eval do yield end end 

我甚至写过类似下面的代码，

  def f(...) instance_eval yield end 

我们经常在该挂block的时候，却把proc对象当参数传给方法了， 或者不明白&p就是block可以直接交给方法使用，我曾经也犯过这样的错误就是因为没有把block和proc正确的区分开来, &p是block, p是proc，不到万不得已的情况下不要显式地创建proc，每当我对block和proc之间的关系犯糊涂时，我就会念上几句。

再来聊聊yield和&p，我们经常这样定义方法，

  def f(...) yield(...) end def f(..., &p) p.call(...) end 

yield和call后面都可以接参数，如果你是这样定义方法

   def f(...) yield 1, 2 end 

那么可以这样执行代码,

   f(...) do |i, j| puts i puts j end 

但是这样做也不会有错,

  f(...) do ... end 

p.call(...)的情况类似, 也就是说block和proc都不检查参数(其实通过proc方法创建的proc在1.8是严格检查参数的，但是在1.9及以上的版本是不检查参数的)，为什么block和proc不检查参数呢?其实这个很好理解，因为在实际应用中你可能需要在一个方法中多次调用block或者proc并且给的参数个数不一样，比如,

  def f()yield 0 yield 1, 2 end def ff(&p) p.call 0 p.call 1, 2, 3 end f do |a1, a2, a3| puts a1 puts a2 puts a3 end 

由于方法后面只能挂一个block，所以要实现上面的代码功能，就不能去严格检查参数了。

转入正题，这两种方式效果差不多，都能很好地利用block。使用yield，看起来简洁，使用&p，看起来直观，并且你可以将&p传给其他方法使用。
但是在 ruby1.8 的版本你不应像下面这样做,

  def f1(...) eval("yield") end 

可以,

  def f2(..., &p) eval("p.call") end 

f1(...) {} # 会抛异常 f2(...) {} # 正常运行 

当然上面这种用法很少见，但是却被我碰到了，我经常写一些方法去请求外部的api，有时这些外部的api不是特别稳定，时不时会遇到一些bad respoense, timeout错误，针对这些错误，应该立即重发报文重试，对于其他异常就直接抛异常。于是我写了一个try方法来满足这个需求，

  def try(title, options = { }, &p) ee = '#{e}' tried_times = 0 max_times = options[:max_times] || 3 exceptions = options[:on] || Exception exceptions = [exceptions] if !exceptions.is_a?(Array) rescue_text = <<-EOF begin p.call rescue #{exceptions.join(',')} => e Rails.logger.info("#{title}发生异常#{ee}") if (tried_times += 1) < max_times Rails.logger.info("开始重试#{title}--第#{tried_times}次重试") retry end raise e end  EOF eval rescue_text end try('某某api', :max_times => 2, :on => [Net::HTTPBadResponse, Timeout::Error]) do open(api_url) end 

最开始我用的是yield，结果在 ree 下执行try方法时会报错，后来改成使用&p就通过了。

通过试验发现在 ruby1.9 及以上版本已经没有这种差异了。

做个小结, block和proc是两种不同的东西, block有形无体，proc可以将block实体化, 可以把&p看做一种运算，其中&触发p的to_proc方法，然后&会将to_proc方法返回的proc对象转换成block 。

其中proc对象的to_proc方法返回自身。

  p = proc {}p.equal? p.to_proc # 返回true 

lambda

lambda是匿名方法, lambda和proc也是两种不同的东西，但是在ruby中lambda只能依附proc而存在，这点和block不同，block并不依赖proc。

  l = lambda {}puts l.class 

在 ruby1.8 中输出的信息类似#Proc:0x0000000000000000irb):1@(
在 ruby1.9 及以上版本输出的信息类似#Proc:0x007f85548109d0irb):1(lambda)@(，注意 1.9 及以上版本的输出多了 (lambda)，从这里可以理解ruby的设计者们确实在有意的区分lambda和proc，并不想把lambda和proc混在一起,如同ruby中没有叫Block的类，除非你自己定义一个，ruby中也没有叫Lambda的类，于是将lambda对象化的活儿就交给了Proc，于是令人头大的情况出现了，当你用lambda弄出了一个匿名方法时，发现它是一个proc对象，并且这个匿名方法能干的活，proc对象都能做，于是我们这些码农不淡定了，Proc.new {}这样可以, proc {}这样也没有问题, lambda {}这样做也不错, ->{}这个还是能行，我平时吃个饭都为吃什么左右为难，现在一下子多出了四种差不多的方案来实现同一件事情，确实让人不好选择，特别是有些码农还有点小洁癖，如果在代码里一会儿看到proc{}, 一会儿看到lambda{},这多不整洁啊，让人心情不畅快。在这里我们认定lambda 或者 -> 弄出的就是一个匿名方法，记做 l, 即使它披着proc的外衣，proc或者Proc.new创建的就是一个proc对象,记做 p 在ruby各个版本中, l 和 p 是有一些差别的。

定义一些方法，

def f0()p = Proc.new {return 0} p.call 1 end def f1() p = proc { return 0 } p.call 1 end def f2() l = lambda { return 0} l.call 1 end def f3(p) instance_eval &p 1 end class A end def f4(p) A.class_eval &p 1 end p1 = Proc.new { } p2 = proc {} l = lambda {} def f5() yield 1, 2 end f5 {} f5 {|i|} f5 {|i,j|} f5 {|i,j,k|} 

lambda和proc之间的区别除了那个经常用做面试题目的经典的return之外，还有一个区别就是lambda不能完美的转换为block(这点可以通过f3和f4执行的过程得证)，而proc可以完美的转换为block,注意，我说的lambda指的是用lambda方法或者->符号生成的proc，当然和方法一样lambda是严格检查参数的，这个特点也和proc不一样。

从上面的数据对比来看，在1.8版本，lambda和proc方法生成的proc对象的行为是一致的，但在1.9以上和jruby的版本中,lambda和proc的不同处增多，可以认为ruby的设计者们并不想把lambda和proc混同为一件事物。如我前面所讲，proc的主要作用是对象化block和lambda，并且proc在行为上更接近于block。

retrun的几个试验

def f0()p = Proc.new { return 0} p.call 1 end def f1() l = lambda { return 0} l.call 1 end f0 # 返回0 f1 # 返回1 

如果你能够理解proc在行为上更像block，lambda其实就是方法只不过是匿名的，那么你对上面的结果不会感到惊讶。

如果把f0,f1做一些修改，就更容易理解上面的结果了。

def f0()return 0 1 end def f1() def __f1 return 0 end __f1 1 end f0 # 返回0 f1 # 返回1 

return只能在方法体里执行，

p = Proc.new { return 0 } l = lambda { return 0 } p.call # 报LocalJumpError l.call # 返回0 

构造p的时候我没有使用proc {return 0}，因为在 ruby1.8 中, proc {return 0}的行为和lambda一样，比如在 ruby1.8 中，

def f(p) p.call 1 end p = proc { return 0 } l = lambda { return 0 } f(p) # 返回1 f(l) # 返回1 p.call # 返回0 l.call # 返回0 def f(p) p.call 1 end p = Proc.new { return 0 } l = lambda.new { return 0} f(p) # 报LocalJumpError f(l) # 返回1 

我感觉proc中的return能记住proc生成时其block的位置，然后无论proc在哪里调用，都会从proc生成时其block所在位置处开始return，有下面的代码为证:

def f(p) p.call 1 end def f2() Proc.new { return 0 } end def f3() lambda { return 0 } end p = f2() l = f3() f(p) # 报LocalJumpError: unexpected return，from (irb):29:in `f2' f(l) # 返回1 

我在1.8, ree, jruby, 1.9, 2.0各版本都测试过，结果一样。

再看看下面的代码,

def f0(&p) p.call 1 end def f1() yield 1 end f0 { return 0} # LocalJumpErrorw f1 { return 0} # LocalJumpErrorw f0(&Proc.new{return 0}) # LocalJumpError f0(&lambda{return 0}) # 返回1 def f2(&p) p end def f3() p = f2 do return 0 end p.call 1 end f3 # 返回0 

我们重点看看f3中的proc p，它虽然是从f2中生成返回的，但是p生成时其block是处在在f3的方法体内，这个类似于，

def f3()p = Proc.new { return 0} p.call 1 end 

所以执行f3时，没有异常抛出，返回0。

总结

当你想写出类似于f do ...; end 或者 f {...}的代码时，请直接使用block,通过yield, &p就能达到目的，当你想使用proc时，其实此时绝大部分的情况是你实际想用lambda,请直接使用lambda{}或者->{}就可以了，
尽量不要显示地使用Proc.new{} 或者 proc{}去创建proc。

废话说了一大堆，其实我最想说的是: 用block，用lambda，不要用proc，让proc做好自己的幕后工作就好了。