我个人对Angular并不十分熟悉，在实现svg和png图片下载功能的过程中遇到一些坑，这些坑有深有浅，深的直接面向stackoverflow编程绕过，浅的靠个人能力解决。只不过，对解决这些浅坑的过度自信却让我的思维陷入懒惰，导致了长时间的浪费。
这里的浅坑就是Javascript臭名昭著的this scope问题。
回顾一下上面有坑的代码，
loadImage(svgDataUrl) .pipe(flatMap(this.toPng)) // 此处有坑 .subscribe(url => { this.pngUrl = url; });
toPng 的代码如下，
private toPng(img: HTMLImageElement): Observable<SafeResourceUrl> { const canvas = document.createElement('canvas'); canvas.width = img.width; canvas.height = img.height; canvas.getContext('2d').drawImage(img, 0, 0); const result = new Subject<SafeResourceUrl>(); canvas.toBlob(blob => { const url = this.sanitizer.bypassSecurityTrustResourceUrl(URL.createObjectURL(blob)); result.next(url); }); return result.asObservable(); }
程序运行时，抛出了一个错误 cannot read bypassSecurityTrustResourceUrl of undefined.
第一反应是我是不是写错了变量名，再三验证之后发现没有写错。然而这一步其实完全没必要，原因在于这些变量都是编辑器辅助补全的。
紧接着，我在 toBlob 方法插入了 console.log(this.sanitizer) ，运行后打印的结果是 undefined 。这能说明什么？程序执行到这里了？其实这种做法也没必要，因为控制台的错误信息明确表明这段代码执行到了，并且出错了。
然后，我开始思考“难道我写的Angular的注入方式不对？”，在遍寻Angular的官方文档和样例之后，我确信注入方式没有问题。这步有可取之处，因为对Angular本身不够熟悉，查文档是合理的行为，但是解决思路离目标太远，程序的问题应该通过debug解决。
无奈之下，我开始怀疑包依赖下载出现问题，所以用了最愚蠢的方法，删除 node_modules ，然后重新下载全部依赖。这是一步耗时的操作，最大的浪费就发生在这里。我把原来对于探索问题总结的基本原则 分析得从最近的路开始 忘得一干二净。尝试无果之后，我没有从牛角尖中跳出来，遗忘了 花时间放空自己 原则，还是持续纠结，直至最后放弃。
第二天早上，喝了杯咖啡，脑袋清醒了些。在 toPng 方法外，我插入 console.log(this.sanitizer) ，发现这个对象完好地出现在命令行中，此刻突然灵感一现，回忆起几年前写过一篇关于Javascript作用域的文章，可不就是this指针的问题么？
loadImage(svgDataUrl) .pipe(flatMap(this.toPng.bind(this))) // 注意此处bind(this) .subscribe(url => { this.pngUrl = url; });
所以用 bind(this) 锁定this的指向，然后发现程序运行正常，一切就都豁然开朗了。值得一提的是，这只是最便宜的修复，其实更可取的做法是写全函数体。
loadImage(svgDataUrl) .pipe(flatMap(img => this.toPng(img))) // 注意此处完整函数体 .subscribe(url => { this.pngUrl = url; });
回想起来，为了节省几个单词，我耗费了好多时间去趟这个坑，这是不值当的。这其中的问题不乏因为我写过很多函数式代码，所以倾向简洁的表达；但是更值得警醒的是，在面临不确定性问题时懒惰的思维方式，用一句套话训斥自己——不要用战术上的勤奋掩饰战略上的懒惰。
我们都知道试验是学习的高效方式，但是切不可乱碰乱撞、期待问题不翼而飞，我们应当遵循经过验证的原则切中要害、一击制胜，切记切记。