如何实现作用域为单查询而非应用级别的静态变量？

我来给你捋捋怎么实现这个查询级别的作用域变量——刚好我之前处理过类似的并行查询上下文隔离需求，有两个靠谱的方案，你可以根据自己的场景选：

如果你想让变量看起来像"静态"但只在单个查询生命周期内有效，.NET里的AsyncLocal<T>简直是为这个场景量身定做的。它能在异步/并行流中自动维护独立的上下文状态，每个查询的处理链都会拥有自己的变量副本，完全不会互相干扰。

先改造你的Environment类，用AsyncLocal存储查询级变量：

public class Environment
{
    // AsyncLocal保证每个查询上下文有独立的ID和变量集合
    private static readonly AsyncLocal<Guid> _queryId = new AsyncLocal<Guid>();
    private static readonly AsyncLocal<Dictionary<string, object>> _values = new AsyncLocal<Dictionary<string, object>>();

    public Guid QueryId
    {
        get => _queryId.Value;
        set => _queryId.Value = value;
    }

    public void SetValue(string key, object value)
    {
        if (_values.Value == null)
            _values.Value = new Dictionary<string, object>();
        
        _values.Value[key] = value;
    }

    public object GetValue(string key)
    {
        return _values.Value?.TryGetValue(key, out var val) == true ? val : null;
    }
}

然后修改你的查询处理逻辑，在每个查询开始时初始化上下文：

ProcessQuery(string query)
{
    var id = Guid.NewGuid();
    var env = new Environment();
    // 给当前查询上下文绑定专属ID和变量
    env.QueryId = id;
    env.SetValue("QueryContextKey", "OnlyForThisQuery");

    var evaluator = CreateEvaluatorBasedOnQuery();
    evaluator.Evaluate(); 
    // 不管Evaluate内部调用多少层级的方法，都能直接通过env拿到当前查询的专属变量
}

这个方案的好处是不用到处传递上下文对象，代码里看起来像用静态变量一样方便，但底层是完全隔离的，非常适合并行处理多个查询的场景。

如果你觉得隐式上下文不够透明，显式传递查询作用域对象会让依赖关系更清晰，调试和维护起来更省心。

先定义一个专门的查询作用域类，把ID和环境变量打包在一起：

public class QueryScope
{
    public Guid QueryId { get; }
    public Environment Env { get; }

    public QueryScope(Guid queryId)
    {
        QueryId = queryId;
        Env = new Environment();
    }
}

然后修改查询处理和Evaluator的逻辑，把作用域对象显式传进去：

ProcessQuery(string query)
{
    var id = Guid.NewGuid();
    var queryScope = new QueryScope(id);
    queryScope.Env.SetValue("QueryContextKey", "OnlyForThisQuery");

    // 创建Evaluator时直接传入专属作用域
    var evaluator = CreateEvaluatorBasedOnQuery(queryScope);
    evaluator.Evaluate();
}

// 改造Evaluator，让它持有当前查询的作用域
public class Evaluator
{
    private readonly QueryScope _currentScope;

    public Evaluator(QueryScope scope)
    {
        _currentScope = scope;
    }

    public void Evaluate()
    {
        // 直接使用当前查询的专属ID和变量
        var currentQueryId = _currentScope.QueryId;
        var contextValue = _currentScope.Env.GetValue("QueryContextKey");
        // 你的业务逻辑...
    }
}

这个方案的优点是依赖关系一目了然，不会出现"变量从哪来"的困惑，适合大型团队或者复杂项目的长期维护。

不管选哪个方案，都能完美支持并行处理多个查询的场景——每个查询的ID和环境变量都是完全独立的，不会出现串数据的问题。

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