在你的触发器函数里面，解开函数调用栈就可以了。三种常用的办法：

1. gcc 内置宏__builtin_return_address：非常粗略的低级方法。这会在堆栈上的每一帧上获得函数的返回地址。注意：只是地址，不是函数名。所以需要额外的处理来获取函数名。
2. glibc 的 backtrace 和 backtrace_symbols：可以获取调用堆栈上函数的实际符号名称。
3. libunwind 库

参考自： https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/

根据上述文章提到的办法，采用 libunwind 库，我简单修改了下它的代码:
1. 代码示例

```
// example.cpp

#include <libunwind.h>
#include <stdio.h>

// Call this function to get a backtrace.
void backtrace() {
unw_cursor_t cursor;
unw_context_t context;

// Initialize cursor to current frame for local unwinding.
unw_getcontext(&context);
unw_init_local(&cursor, &context);

// Unwind frames one by one, going up the frame stack.
while (unw_step(&cursor) > 0) {
unw_word_t offset, pc;
unw_get_reg(&cursor, UNW_REG_IP, &pc);
if (pc == 0) {
break;
}
printf("0x%lx:", pc);

char sym[256];
if (unw_get_proc_name(&cursor, sym, sizeof(sym), &offset) == 0) {
printf("(caller function: %s+, offset: 0x%lx)\n", sym, offset);
} else {
printf(" -- error: unable to obtain symbol name for this frame\n");
}
}
}

void foo1() {
backtrace(); // <-------- backtrace here!
}

void foo2() {
backtrace(); // <-------- backtrace here!
}


int main(int argc, char **argv) {
foo1(); // <-----在函数 foo1()和 foo2()中可以看到整个的调用栈。
printf("\n");
foo2();
return 0;
}

````

2. 编译前安装依赖（以 ubuntu 为例）:
sudo apt install libunwind-dev

3. 编译指令:
g++ -o example example.cpp -L /usr/local/lib -lunwind

用 handler 比用 if 会更好吗？ handler 里面不一样还是要用 if 写一堆判断？一个函数里面的内部需要返回不同的错误。

这个草案是不可能被通过的。
因为这违背了 Golang 的基本设计哲学：错误是值。
https://go.dev/blog/errors-are-values

不直接去返回那个（错误的）值，却放在 handler 里面去返回，不是在搞笑吗？这会让你同一逻辑的代码在空间上分离。比如一个函数 和它的错误处理在代码的空间上分离，这绝对更加不利于代码的可读性。if err != nil { ... } 只是丑陋了一点，但是可读性仍然是良好的。

golang ，永远不太可能有除了 if err != nil { ... } 之外的错误处理方案，因为它的设计哲学决定了这个。除非它改变设计哲学。像 Python 的做法是把错误当成异常，而不是值。

你这个问题，也是过去历代计算机科学家想要攻克的问题。你可以读一读 Dijkstra 1972 年的图灵演讲。
英文版： https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
中译版： https://www.ituring.com.cn/article/71467

他提到了：
“论据三是建立在程序正确性问题的建设性方法上的。今天，一项普通的技术就是写一个程序，然后去测试。 尽管，程序测试是一种非常有效的方法去暴露 bugs ，但对证明不存在 bugs 几乎是完全没用的。显著提高程序可信度唯一有效的方法是给出一个令人信服的关于正确性的证据。但是我们不应该首先写出程序，然后去证明它的正确性，因为要求证明只会增加苦逼程序员的负担。相反，程序员应该让正确性证明和程序相互验证，发展。论据三本质上是从以下的观察得来的。如果一个人问自己一个令人信服的证据应该具备什么，他了解后，写了一个很好的满足了证明要求的程序，然后这些关于正确性的担心变成一种有效的启发式的指导。当我们把自己限制在智能可控程序时，按照定义，只有这种方法是可行，但这种方法也提供许多有效的方法，让我们从中挑选一个满意的。”

他的思想是测试驱动开发（ TDD ）：先写好验证的测试，把所有可能的情况考虑到，再写程序。你只需要说明你写用于测试的程序是有效的（基于合理正确的思维逻辑），只要能测试通过，那么你写的被测试的程序必然是正确的。

但这个毫无疑问会增加程序员的工作量和负担。对足够优秀的程序员来说，我觉得一定是不必要的负担。

我通常只对不稳定的函数和接口添加测试。有些函数的参数来源于不可控的外部数据源，比如要读取一个文本，读取到的数据各种可能性都有，这个时候就要添加测试程序，只是用来验证和保证被测试程序的正确性。

聊聊天啊，让他自立。
不愿意找工作，可能是找工作受了挫折，没有信心，多鼓励鼓励。
强硬点就扫地出门了，让他自己成长。

错误：“很可能也解决和发现什么问题”
修正：“很可能也发现和解决不了什么问题。”

一般说来，web 服务不涉及 CPU 密集型的任务。比较依赖 CPU 资源的主要在于解码或数学计算类的任务。所以即便你找到了好工具，很可能也解决和发现什么问题。

大多数程序性能的障碍在于：内存数据的写读依赖，不必要的计算和循环，算法的选择，不必要的 I/O 操作，多进程的数据竞争。你可以在程序内用通过日志输出高精度的时间，直接来捕捉到影响性能关键的代码区域，重新看代码逻辑分析具体是什么原因。

以「不必要的计算和循环」为例，我就遇到这样的代码，比如明明一个 for 循环就可以直接完成 AB 操作。但是有的程序员，会先写一个 for 循环执行 A 操作，再来一次 for 循环执行 B 操作。就导致了无谓的双倍内存访问。在比如明明一次 SQL 查询就能解决问题，他要查询两次，然后对数据进行关联和处理。就是不必要的操作和计算。

通常情况，性能的问题是人的问题。

国内就没有不卷的公司，只是程度的差异不同。
有些公司迭代的节奏相对慢一点。

现在的安卓早已不是性能问题了，而是缺乏统一的应用市场和严格的审核机制。
由此导致了良莠不齐的 APP——各种广告，索取权限和侵犯隐私，无底线的唤醒和消息通知。

这种东西肯定都有现成的，自己动手用搜索引擎。中文搜不到就用英文搜。

https://slideplayer.com/slide/8527032/
https://www.slideshare.net/sohagmis/cross-border-e-commerce
https://www.cemla.org/forodepagos/pdf/week2017/2017-09-semanadepagos26.pdf