这里的主要问题是Z的foo()没有任何约束，但它的实现期望表达式T().foo()是良好格式的，这将在T没有foo()时在函数体内部导致硬错误，因为concept只检查函数的签名。
最直接的方法是约束Z::foo()以符合其内部实现（尽管这也要求T是默认可构造的）。

template<typename T>
struct Z {
  auto foo() requires HasFoo<T> {
    T().foo();
  }
};

根据@PatrickRoberts的评论，我们不能SFINAE模板或检查函数的存在，其中存在依赖于模板的内部实现，这可能会导致编译错误，因为需要解析模板，这可能会遇到会导致硬错误的替换失败，或者是一个错误的答案--在问题结尾的if constexpr的意义上是错误的。
看起来，唯一能把我们从上面拯救出来的是实现模板本身的人。
例如，我们可以如下实现Z：

template <typename T>
concept HasFoo = requires(T t) {
    t.foo();
};
template<typename T>
struct Z {};
template<HasFoo T>
struct Z<T> {
    void foo() {
        T().foo();
    }
};

现在我们可以安全地使用Z：

struct X {
    void foo() {}
};
struct Y {};
static_assert(HasFoo<X>);
static_assert(!HasFoo<Y>);
// static_assert(HasFoo<Z<Y>>); // would fail, justifiably
static_assert(!HasFoo<Z<Y>>); // passes
template<typename T>
void lets_foo(T t) {
    if constexpr(HasFoo<T>) {
        t.foo();
    }
}
int main() {
    lets_foo(X{}); // ok, calls foo inside
    lets_foo(Y{}); // ok, doesn't call foo inside
    lets_foo(Z<X>{}); // ok, calls foo inside
    lets_foo(Z<Y>{}); // ok, doesn't call foo inside
}

Code link
现在，如果我们想查询多个成员，会发生什么？我们也许应该使用Mixin，就像这样：

template<HasFoo T>
struct Fooable {
    void foo() {
        T().foo();
    }
};
template<HasMoo T>
struct Mooable {
    void moo() {
        T().moo();
    }
};
template<typename T>
struct Z {};
template<HasFoo T>
struct Z<T>: Fooable<T> {};
template<HasMoo T>
struct Z<T>: Mooable<T> {};
template<typename T>
    requires HasFoo<T> && HasMoo<T>
struct Z<T>: Fooable<T>, Mooable<T> {};

现在允许：

template<typename T>
void lets_foo_and_moo(T t) {
    if constexpr(HasFoo<T>) {
        t.foo();
    }
    if constexpr(HasMoo<T>) {
        t.moo();
    }
}
int main() {
    lets_foo_and_moo(X{}); // ok, calls foo inside
    lets_foo_and_moo(Y{}); // ok, calls nothing
    lets_foo_and_moo(Z<X>{}); // ok, calls foo inside
    lets_foo_and_moo(Z<Y>{}); // ok, calls nothing
}

Code link
无论如何，负担都在模板实现者身上，假设他们知道这个需求。
在发布了我的答案之后，我现在看到了the solution proposed by @康桓瑋，我必须说它更简单和优雅（尽管Mixin方法在某些情况下可能有用）。

C++不要求编译器在替换失败发生之前完全示例化所有代码。
这是因为编译器编写者认为这样做很难。
通常，方法的主体内的失败会导致硬编译时错误。在不修改方法本身的情况下，不存在检测此类故障的方法，并且这是有意的。在编译方法体时检测到错误，编译可以立即停止，没有回退。
当SFINAE（替换失败不是错误）是唯一的实现这种事情的技术时，没有失败硬的方法被称为“SFINAE友好”。
在概念时代，它看起来像：

void foo() requires HasFoo<T> {

而不是

void foo() {

预先概念，您可以进行手动检查，或使用宏，如：

#define RETURNS(...) -> decltype(__VA_ARGS__) { return __VA_ARGS__; }

然后做

auto foo() RETURNS( T().foo() }

它做了一些类似的事情。
这个问题-方法中的硬错误-发生在std库中。例如，vector的operator<被定义为在其包含的值上简单地调用<-如果失败，则错误是硬错误。
我在过去用per-std-container专门化来解决这个问题，它检测所包含类型的需求并（手动）推导容器属性。
避免这种手工工作的唯一方法是与你交互的类型进行合作。