至少从我的阅读和实验来看，我认为不修改底层的Ginkgo代码是不可能做到这一点的。Ginkgo使用自己的报告框架，你可以利用它来定制输出......在一定范围内。
查看原始报告输出的一种方法是将其转储为json，并为ginkgo添加--json-report <PATH>标志：

$ ginkgo --json-report=spec-out.json

我创建了一个简单的规范来比较两个非常长的字符串（只是英语字母表重复，用空格分隔，重复了很多次），不同之处仅在于用“foobar”替换了一个字母表块，报告的内容与您在正常输出中看到的内容相关，仅限于：

"Failure": {
          "Message": "Expected\n    \u003cstring\u003e: \"...wxyz abcdef...\"\nto equal               |\n    \u003cstring\u003e: \"...wxyz foobar...\"",

然后，我修改了比较字符串，使其diff扩展了更长的范围，并且消息是相同的-仍然截断到初始的不匹配点。
您可以通过Ginkgo本身访问基础报告框架，例如：

ReportAfterEach(func(report SpecReport) {
        fmt.Fprintf(os.Stderr, "SPEC REPORT: %s | %s\nFAILURE MESSAGE: %s\n", report.State, report.FullText(), report.FailureMessage())
    })

这也返回了消息中被截断的字符串，这向我表明，没有容易访问的机制来获取更长的字符串以输出-因为这可能是在较低级别生成的（我在考虑Equal()匹配器的代码，但我还没有看）：

SPEC REPORT: failed | Utils Compares really long strings
FAILURE MESSAGE: Expected
    <string>: "...wxyz abcdef..."
to equal               |
    <string>: "...wxyz foobar..."

有关参考，请参阅银杏报告文件和银杏godoc的相关部分。