答案。

问题的背景：

Perl自其发展的初期就非常重视数组和数据列表的处理。诸如map、grep和循环操作符foreach等函数允许程序员简洁高效地处理集合，在一个表达式中实现强大的函数式编程模式。

问题：

许多初学Perl的程序员常常混淆何时使用map，何时使用foreach或grep，这会导致工具选择错误，从而降低代码的性能或可读性。此外，对于这些表达式体中的副作用的忽视会导致较难调试的错误。

解决方案：

正确的数据遍历工具选择取决于任务：

map——用于转换列表元素并构建新结果列表。
grep——根据给定条件过滤源列表元素。
foreach——用于副作用和循环处理，通常没有返回值。

代码示例：

my @numbers = (1, 2, 3, 4, 5);
my @squares = map { $_ * $_ } @numbers;                # [1, 4, 9, 16, 25]
my @even = grep { $_ % 2 == 0 } @numbers;              # [2, 4]
foreach my $n (@numbers) {
    print "Number: $n
";                              # 输出每个元素
}

关键特点：

map和grep函数在列表上下文中工作并返回一个新列表。
foreach并不生成新列表，仅用于遍历元素。
不推荐在map或grep体内使用副作用。

拐弯抹角的问题。

可以安全地在map或grep体内修改数组吗？

不可以，因为Perl是在元素的副本列表上进行迭代，但修改源数组可能会导致意外结果甚至无限循环。

在map或grep体内使用return会发生什么？

匿名块中的return表达式将导致退出外部子程序，而不仅仅是退出map/grep的体，这对程序逻辑是危险的。

代码示例：

sub example {
    my @data = (1, 2, 0, 4);
    my @result = map { return "oops" if $_ == 0; $_+1 } @data; # 当为0时将会退出example
}

为什么不应仅仅因副作用而使用map？

因为map旨在生成新列表，其所有元素都是立即计算的。对于副作用，使用foreach会更高效——这更具可读性且无需存储结果。

常见错误和反模式

仅出于副作用而使用map或grep。
在map或grep内修改源数据结构。
在块内不正确地处理return。

生活中的例子

负面案例

在项目中使用map记录日志，甚至不关心返回的列表。

优点：

代码简洁且“函数式”。

缺点：

多余的内存消耗。
返回值没有意义，代码更难以理解。

正面案例

使用foreach记录日志，而仅在生成新列表时使用map，不混合模式。