好问题！这确实是完美转发场景里很容易踩的坑——当你打算把资源通过std::move移交给函数，结果函数可能失败需要重试时，第一次move会直接把调用方手里的资源掏空，根本没法再来第二次。下面分享几种适配完美转发的解决方案，你可以根据自己的场景选：

1. 返回未消耗的资源（最常用的方案） #

核心思路是让函数不仅返回成功与否，还要把未被消耗的参数资源一起返回给调用方。这样哪怕失败了，你还能拿着返回的资源继续重试。

比如我们可以定义一个包含结果状态和参数的结构体：

#include <tuple>
#include <utility>

template<typename A, typename B>
struct FooResult {
    bool success;
    A retained_a;
    B retained_b;
};

// 注意用std::decay_t处理引用类型，确保我们存储的是值类型
template<typename A, typename B>
FooResult<std::decay_t<A>, std::decay_t<B>> foo(A&& a, B&& b) {
    // 先尝试执行操作
    if (some_failure_condition) {
        // 失败了，把原参数（可能还没被修改）返回给调用方
        return {false, std::forward<A>(a), std::forward<B>(b)};
    }

    // 成功的话，消耗掉资源（这里可以做你的业务逻辑）
    process_resource(std::forward<A>(a), std::forward<B>(b));
    // 返回成功状态，资源已经被消耗，所以返回默认构造的空值即可
    return {true, {}, {}};
}

调用方的代码就可以这样写：

X x;
Y y;

auto result = foo(std::move(x), std::move(y));
while (!result.success) {
    // 如果需要，可以先对retained_a和retained_b做一些修复（比如重置状态）
    result = foo(std::move(result.retained_a), std::move(result.retained_b));
}

这个方案的好处是逻辑清晰，不需要额外的包装类，而且完美保留了完美转发的特性。

2. 使用所有权代理包装器 #

如果不想让函数返回复杂的结构体，可以用一个自定义的包装类来管理资源的所有权转移。这个包装类可以让函数尝试获取资源所有权，失败时再把资源“还回去”。

比如：

#include <optional>
#include <utility>

template<typename T>
class OwnableResource {
public:
    explicit OwnableResource(T&& resource) : m_resource(std::move(resource)) {}

    // 尝试获取资源所有权，成功则返回std::optional<T>，失败返回空
    std::optional<T> take() {
        if (m_resource.has_value()) {
            return std::move(m_resource.value());
        }
        return std::nullopt;
    }

    // 把资源放回包装器（供失败时复用）
    void give_back(T&& resource) {
        m_resource = std::move(resource);
    }

    bool has_resource() const {
        return m_resource.has_value();
    }

private:
    std::optional<T> m_resource;
};

template<typename A, typename B>
bool foo(OwnableResource<A>&& a_wrap, OwnableResource<B>&& b_wrap) {
    auto a = a_wrap.take();
    auto b = b_wrap.take();

    if (!a || !b) {
        return false;
    }

    // 尝试执行操作
    if (some_failure_condition) {
        // 失败了，把资源放回包装器
        a_wrap.give_back(std::move(*a));
        b_wrap.give_back(std::move(*b));
        return false;
    }

    // 成功则消耗资源
    process_resource(std::move(*a), std::move(*b));
    return true;
}

调用方的使用方式：

X x;
Y y;

OwnableResource<X> a_wrap(std::move(x));
OwnableResource<Y> b_wrap(std::move(y));

while (!foo(std::move(a_wrap), std::move(b_wrap))) {
    // 只要失败，a_wrap和b_wrap里的资源就会被放回，可以继续重试
}

这个方案适合对所有权管理有明确要求的场景，逻辑更严谨，但需要额外编写包装类。

3. 拆分“预检查”和“执行”两步 #

如果函数的失败可以通过不修改参数的预检查提前判断，那可以把操作拆成两步：先做预检查确认能成功，再移动参数执行。这样可以避免因为预检查失败而浪费资源。

示例代码：

// 预检查：只做只读操作，确认是否可以执行
template<typename A, typename B>
bool foo_preflight(const A& a, const B& b) {
    // 比如检查资源是否合法、权限是否足够等
    return is_resource_valid(a) && has_permission(b);
}

// 执行：真正消耗资源的操作，假设预检查通过后不会失败（如果还是可能失败，结合方案1）
template<typename A, typename B>
bool foo_execute(A&& a, B&& b) {
    process_resource(std::forward<A>(a), std::forward<B>(b));
    return true;
}

调用方代码：

X x;
Y y;

while (true) {
    if (foo_preflight(x, y)) {
        if (foo_execute(std::move(x), std::move(y))) {
            break;
        } else {
            // 如果执行还是失败了，需要重新创建资源
            x = create_new_x();
            y = create_new_y();
        }
    } else {
        // 预检查失败，修改参数状态后重试
        adjust_resource(x);
        adjust_resource(y);
    }
}

这个方案适合失败原因大多可以提前检测的场景，能大幅减少重试时的资源消耗。

4. 保留参数副本（简单但有局限） #

如果你的参数类型是可复制的，而且复制成本不高，那最简单的方式就是调用方保留一个副本，每次重试都用副本的move版本：

X x;
Y y;
X x_copy = x;
Y y_copy = y;

while (!foo(std::move(x_copy), std::move(y_copy))) {
    // 每次重试前重新复制原始资源
    x_copy = x;
    y_copy = y;
}

当然，这个方案的局限性很明显——如果资源很大（比如大内存块、文件句柄），复制成本太高，就不适合用了。

总结下来，返回未消耗资源的方案是最通用的，几乎适配所有场景；如果对所有权管理有要求，代理包装器是不错的选择；预检查+执行适合失败可提前检测的情况；副本法则只适合轻量可复制的参数。

内容的提问来源于stack exchange，提问作者user534498