js파일 캐시의 버전관리에 대한 자세한 설명_기본지식

최근 몇 달간 진행된 작업은 트레이딩 시스템의 지속적인 개선 프로젝트로, 약 2~3주 정도의 반복적인 릴리스 주기를 갖습니다. 최신 버전은 수요일에 출시된 V16 버전입니다. 불행하게도 그는 다음날 아침 상사에게 붙잡혔습니다. 알고 보니 사장님이 제작 중 버그를 발견한 것이었습니다. 일반적인 문제는 다음과 같습니다.

시스템에는 고객 선택을 돕기 위해 일반적으로 사용되는 사용자 정의 컨트롤이 있으며 V16 버전의 지속적인 개선 요구 사항은 컨트롤에 두 가지 필터링 옵션을 추가하여 다양한 기본값 구성을 지원하는 것입니다. 이는 매우 간단한 요구 사항이며 코드 수정도 간단합니다. 수정 중 하나는 구성 값을 전달하기 위해 js 파일의 함수에 들어오는 매개 변수를 추가하는 것입니다. RC 및 RTW 테스트 후 모든 것이 정상으로 보였지만 버그는 프로덕션에 투입된 후에야 발견되었습니다. 로드된 고객은 분명히 비정상이고 숫자가 잘못되었으며 예상 쿼리 구성과 일치하지 않습니다.

컨트롤의 내부 점프 링크를 확인하고 문제를 찾으십시오. 전달된 매개 변수가 예상과 분명히 일치하지 않으며 이 링크는 위에서 수정된 JS 함수에 의해 생성됩니다. 따라서 클라이언트가 원본 JS 파일을 캐싱하고 새 함수 호출이 이전 함수로 대체되어 문제가 발생한 것으로 판단됩니다. 캐시를 지우고 페이지를 다시 로드하면 이 사용자 정의 컨트롤이 정상적으로 작동할 수 있습니다. 안타깝게도 모든 사용자에게 전화를 걸어 이 기능을 사용하기 전에 캐시를 지워야 한다고 말할 수는 없습니다.

이 시점에서 저는 JS의 캐싱 문제를 제어할 방법이 필요하다는 것을 깨달았습니다. 그렇지 않으면 JS 파일의 내용과 관련된 후속 수정으로 인해 캐시가 최신 JS 파일을 얻을 수 없기 때문에 생산 사고가 발생할 수 있습니다.

원칙적으로 JS 업데이트가 있을 때마다 JS 파일을 다시 로드해야 합니다. 따라서 첫 번째 접근 방식은 JS 애플리케이션 주소 뒤에 임의의 매개변수를 추가하는 것은 바람직하지 않습니다. 페이지가 로드될 때마다 JS가 다시 로드되고 캐시된 JS가 제대로 활용되지 않습니다. 그러나 우리는 좀 더 합리적인 두 번째 접근 방식을 가지고 있습니다. 일부 외국 웹사이트 코드에 주의를 기울이면 일반적으로 js 코드 뒤에 임의의 숫자 대신 버전 번호 매개변수가 추가된다는 것을 알 수 있습니다. is Modified 이때 버전 번호에 1만 추가하면 클라이언트에 js 파일을 업데이트하라고 알리는 문제를 교묘하게 해결할 수 있습니다. 이 방법을 처음 생각해낸 사람이 누구인지는 모르겠지만, 정말 좋은 생각인 것에는 의심의 여지가 없습니다.

몇 가지 코드와 함께 제공: