SPFx Web Part中重写window.sessionStorage方法是否安全可靠？

你的临时方案能解决当前TaxonomyPicker的存储问题，但存在全局污染风险，长期来看不可靠，核心问题及改进方向如下：

核心风险点 #

• 跨页面全局影响：sessionStorage是同域会话级存储，你重写的setItem/getItem会作用于当前浏览器标签页内的所有SharePoint页面。其他页面如果未引入LZ压缩库，读取带lz:前缀的缓存内容会直接报错；即使引入了库，也可能被你的压缩逻辑意外修改自身的存储数据。
• 原生API兼容性隐患：重写浏览器原生存储方法可能触发未知兼容性问题，比如部分浏览器对存储事件的监听逻辑、配额超限的处理机制，都可能因你的重写逻辑被干扰。
• 维护成本高：后续如果升级SPFx依赖、更换控件版本，或其他页面引入新的存储逻辑，你的全局重写代码会成为排查问题的隐性障碍。

改进方案 #

1. 卸载时恢复原生方法（最小侵入临时修复） #

在Web Part卸载时恢复sessionStorage的原生方法，避免影响其他页面：

fixSetItemFunc = (): void => {
    const lzPrefix = 'lz:';
    const threshold = 5000;
    if (!this.oldSetItemFunc) {
        this.oldSetItemFunc = window.sessionStorage.setItem.bind(window.sessionStorage);
        this.oldGetItemFunc = window.sessionStorage.getItem.bind(window.sessionStorage);
        
        const setItem = (key: string, value: string) => {
            let compressedValue: string;
            if (value && value.length > threshold) {
                compressedValue = lzPrefix + LZ.compress(value);
            } else {
                compressedValue = value;
            }
            this.oldSetItemFunc(key, compressedValue);
        };
        window.sessionStorage.setItem = setItem;

        const getItem = (key: string) => {
            const value = this.oldGetItemFunc(key);
            let decompressedValue: string;
            if (value && value.length && value.substring(0, lzPrefix.length) === lzPrefix) {
                decompressedValue = LZ.decompress(value.substring(lzPrefix.length));
            } else {
                decompressedValue = value;
            }
            return decompressedValue;
        };
        window.sessionStorage.getItem = getItem;
    }
}

// 组件卸载时恢复原生方法
componentWillUnmount() {
    if (this.oldSetItemFunc && this.oldGetItemFunc) {
        window.sessionStorage.setItem = this.oldSetItemFunc;
        window.sessionStorage.getItem = this.oldGetItemFunc;
        this.oldSetItemFunc = undefined;
        this.oldGetItemFunc = undefined;
    }
}

2. 针对性处理缓存Key（更安全的方案） #

找到TaxonomyPicker控件使用的sessionStorage Key前缀（比如控件源码中可能用pnp-taxonomy-之类的前缀），仅对这些Key做压缩/解压处理，不全局重写API：

const taxonomyKeyPrefix = 'pnp-taxonomy-'; // 替换为控件实际使用的Key前缀
const lzPrefix = 'lz:';
const threshold = 5000;

// 封装自定义存储方法，仅处理Taxonomy相关Key
const customSetItem = (key: string, value: string) => {
    if (key.startsWith(taxonomyKeyPrefix) && value.length > threshold) {
        window.sessionStorage.setItem(key, lzPrefix + LZ.compress(value));
    } else {
        window.sessionStorage.setItem(key, value);
    }
};

const customGetItem = (key: string) => {
    const value = window.sessionStorage.getItem(key);
    if (key.startsWith(taxonomyKeyPrefix) && value?.startsWith(lzPrefix)) {
        return LZ.decompress(value.slice(lzPrefix.length));
    }
    return value;
};

// 然后在控件初始化前，将其内部的sessionStorage调用替换为自定义方法
// （需通过控件的配置或源码修改，若旧版本支持自定义缓存则更简单）

总结 #

当前方案仅适合紧急临时场景，建议优先采用「卸载恢复原生方法」降低全局影响，长期来看最好针对性处理控件的缓存逻辑，避免污染全局API。

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